Llms are getting quite good at decompiling things to idiomatic code. How much better do they have to get before open source is a moot point?

Open source is as much about the source as it is about the license. Having a source you don’t have the rights to is not worth much.

Too late now, but is the requirement for shared mutable state inherent in the problem space? Or is it just because we still thought OOP was cool when we started on the DOM design?

Yes. It is required for W3C's DOM APIs, which give access to parent nodes and allow all kinds of mutations whenever you want.

Event handlers + closures also create potentially complex situations you can't control, and you'll need a cycle-breaking GC to avoid leaking like IE6 did.

You can make a more restricted tree if you design your own APIs with immutability/ownership/locking, but that won't work for existing JS codebases.

Worst case is that it doesn't even cause correctness issues in normal use, only when misused in a way that is unlikely to happen unintentionally.

I guess because I work in security the "unintentionally" doesn't matter much to me.

But it matters for detection time, because there's a lot more "normal" use of any given piece of code than intentional attempts to break it. If a bug can't be triggered unintentionally it'll never get detected through normal use, which can lead to it staying hidden for longer.

That's not really contested? The statement was that longer detection time indicates lower severity.

But those segfaults will either be memory memory safe or your lines will contain “unsafe” or “unchecked” somewhere.

You can make a fully safe segfault the same way you can in go. Swapping a base reference between two child types. The data pointer and vft pointer aren't updated atomically, so a thread safety issue becomes a memory safety one.

This is no longer allowed with strict concurrency

When did that happen? Or is it something I have to turn on? I had Claude write a swift version of the go version a few months ago and it segfaulted.

Edit: Ah, the global variable I used had a warning that it isn't concurrency safe I didn't notice. So you can compile it, but if you treat warnings as errors you'd be fine.

Maybe home cooking is, but every restaurant meal I bhave eaten near the Mediterranean had seafood or cheese in it.

Edit: you said vegetarian not vegan, and yeah lot of pasta dishes are vegetarian but not vegan.

I don't think it is meant to read left to right but top to bottom. Chicken and broccoli are top center, and that is the standard weight lifter meal plan. That said, human dietary needs vary individually by far more than any lobbied leaders will ever communicate.

The website is animated, so there's no question of which direction to read in, the left side literally pops up first lol. I can't lie, I miss websites that stood still, this could've just been a PDF.

BTW, you say "lobbied leaders" -- if you're talking about the scientists who have their names on this report, you'd be very correct. The "conflicting interests" section has loads of references to the cattle and dairy industries.

Authoritarian regimes very rarely get reverted if they aren't external powers ruling a separate group. Can you give some examples where it happened? I don't know of any that lasted very long.

I am a dsp expert. I still find it's explanations delightful and useful perspectives. Also very good for new team members who are better at code than dsp, which is most of them.

Thanks both. Appreciate the insight.

Rust certainly isn't a pure fp language, but the borrow checkerbl is a lot kinder when you use fp style.

Sure, my point was simply that it’s not as simple as the author assumes. This is a common failure mode in FP advocacy and it’s disappointing because it usually means that a more interesting conversation doesn’t happen because most readers disengage.

I get why it reads like FP evangelism, but I don’t think it’s “ignoring decades of prior art.” I’m not claiming these ideas are exclusive to FP. I’m claiming FP ecosystems systematized a bundle of practices (ADT/state machines, exhaustiveness, immutability, explicit effects) that consistently reduce a specific failure mode: invalid state transitions and refactor breakage.

Rust is actually aligned with the point: it delivers major reliability wins via making invalid states harder to represent (enums, ownership/borrowing, pattern matching). That’s not “FP-first,” but it’s very compatible with functional style and the same invariants story.

If the TS example came off as “types instead of validation,” that’s on me to phrase better, the point wasn’t “types eliminate validation,” it’s “types make the shape explicit so validation becomes harder to forget and easier to review.”

I would keep in mind how much the title communicates your intentions on future posts. The conversation about preventing invalid states has to be somewhat inferred when it could have been explicitly stated, and that’d be really useful comparing other approaches - e.g. the classic OOP style many people learned in school also avoid these problems as would something like modern Python using Pydantic/msgspec so it’d be useful to discuss differences in practice, and especially with a larger scope so people who don’t already agree with you can see how you came to that position.

For example, using the input parsing scenario, a Java 1.0 tutorial in 1995 would have said that you should create a TimeDuration class which parses the input and throws an exception when given an invalid value like “30s”. If you say that reliability requires FP, how would you respond when they point out that their code also prevents running with an invalid value? That discussion can be far more educational, especially because it might avoid derails around specific issues which are really just restating the given that JavaScript had lots of footgun opportunities for the unwary developer, even compared to some languages their grandmother might have used.

You can do the same thing with types or the wide crate. But it isn't always obvious when it will become a problem. Usung these types does make auto vectorization fairly reliable.