I have strong opinions on the superiority of #2 to #1 because I've dealt with endless bugs caused by people who think they can handle #1 and can't. Reasoning about complex memory order rules and thread interleaving is extremely difficult for both humans and AIs. That's why we abstract over raw threads with actors, STM, fork/join facilities, and (my favorite) structured cooperative concurrency. It's not a knock against anyone's skill to point out that EVERYONE gets concurrency wrong and we need guardrails on top.

That said, let's be honest: the JS ecosystem has a culture that'll make #1 worse than it usually is. There's a certain combination of insularity and lack of restraint I've observed in the JavaScript world that prompts its members to re-learn the hard way all the painful lessons in software history.

In addition to lifetime management, GC gives you compaction, pointer compression, and fast bump-pointer allocation that doesn't depend on being able to represent your lifetimes as nested arenas.

Modern GC is excellent. Replacing it with manual allocation isn't better, even with guardrails: reference counting is expensive, atomic reference counting doubly so, and free() itself is very far from free.

Sure, you can restrict lifetime shapes, but when you do that, people switch to allocating out of arrays and using indices as pointers, so you're right back where you started with respect to lifetime management.

So what are you saving? You're just replacing the high-performance concurrent mark/sweep microsecond-pause GC someone has written and debugged for you for free with custom convoluted logic that'll probably leak and run slower besides. Why would anyone want this trade?

The elevation of manual memory management to standard performance practice is a generational mistake this industry is making.

The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space.

There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer.

If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database.

The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.

My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things.

The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store.

JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming.

Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.

I was right. Buried in the middle of the post is this tidbit:

> v1 collects synchronous and stop-the-world

Ah, there it is! I knew it!

Parallel garbage collection is a very hard problem. Years of experience and subtle implementation are required to get something like ZGC. A stop-the-world garbage collector will kill tail latency in many use-cases, especially for large programs. I'd say a good GC is the hardest part of a modern VM, even harder than a good JIT: not that a JIT is easy.

Show me multi-threaded JS with generational mark, sweep, compaction, etc. running in parallel with the mutator and I'll be impressed. (The smart thing would be to base it on the JVM or CLR. Doesn't count though.)

It's all so exhausting, this current programmer culture of doing the easy part of a system thing X and presenting your work, without qualifiers, as a complete and modern X.

Sure, sure, we can have memory safe C (just don't have any data races!). Sure, we can have an AI C compiler (just don't expect type checking). Sure, we can port SQLite to Rust (but don't expect it to be fast). Sure, you can one shot a Slack clone (just don't expect performance or security). Doing the easy part of a thing is not doing the thing! You can't trust a README's feature list these days.

To be fair, given that the README is obviously unedited LLM output, the authors might not have realized that their agents cheated and made threading easy by pessimizing the GC. The LLM certainly did though.

Now, maybe the JSC really is adaptable to a multi-threaded mutator world. If it is, great. But over and over, I've seen AI say "I will defer and charter $HARD_THING" and mean "I have no idea how to do $HARD_THING, so I'm creatively reinterpreting your request to make it easy". You have to be endlessly vigilant for LLMs subtly twisting your tasks into easy versions that might technically meet the requirements but they are less complete than you intend.

How do you associate metadata with a public name? A SRV record! No, a TXT record! No, a meta tag! No, data attributes! No, an X.509 attribute! No, a random file at top level! No, a well known file under some schema! No, ...

It goes on forever. We're left with a mishmash of mechanisms and lowest common denominator support for them all.

It would be nice if we picked an extension mechanism and maximally enhanced it rather than having everyone invent his own

Say you have one time series with CPU-core task switches:

T=1 task=A T=3, task=B, T=5 task=A, ...

... and another of CPU frequency changes ...

T=2 freq_hz=800, T=5 freq_hz=1200, T=6 freq_hz=900

How, in SQL, do you express the question "How many CPU cycles did each task use?"? Try to do it with more complex examples. You'll tear your hair out.

Having worked on this sort of data analysis quite a lot, I'm strongly of the opinion that SQL needs syntax, not just table-valued functions, for expressing questions about timelines.

See https://dancol.org/dctv/index.xml

I still think there's a lot of value in first-class syntax for time queries. Splitting ranges like Postgres 19 does is a good first step, but there's also a lot of power in broadcasting over these ranges, combining them in various ways, and storing multiple, independent ranges in a single table.

Ignore the bit about active development: these days, it'd take more sense to add the operators I describe to Postgres and DuckDB than to make a numpy-based engine just to host the analysis. This work predates DuckDB, and it's reassuring that DuckDB (and now Postgres) are thinking along similar lines.

I'm also glad that in the intervening years "data lake"-style analysis has become more prominent. My ideal data processing pipeline consists of sourcing from raw data and pipelining views all the way to human-meaningful outputs. Materialization, if it occurs, is just an optimization.

> negative, which is literally impossible.

Impossibility proofs are common in mathematics, physics, and computer science. This paper is not one of them. It reports an observational gap. That's not the same thing at all as showing, e.g. that any transformer no matter how large or interconnected, can't compute some function.

> our brains

Airliners don't have feathers.

> we clearly haven’t really seen major architectural changes for transformers for a few years now.

Ever read a DeepSeek paper? Ever hear of MLA? Mamba? Or gated deltanet? Or RLMs? Universal transformers? There's been a deluge of architectural advancement over the past few years. You shouldn't go around asserting the burden of proof falls on this or that party if you're not familiar enough with the recent literature to recognize the kinds of proof that would satisfy this burden.

> deficiencies will remain even if we figure out ways to paper over it on a case by case basis.

I think there are general solutions unknown to us for classes of problem we solve one by one through brute force today. Not arguing that. I just don't accept that the path to generality goes through giving up "transformers", whatever this term means after the architectural Cambrian explosion of the past few years.

It's much more likely that further capability unlocks involve in-the-weights continuous online learning. How we do that is orthogonal to whether the weights encode a transformer, a diffusion model, a SSM, or something more exotic.

Sure, these things aren't pure transformers. But neither are frontier models. The industry is already doing what you suggest and moving beyond naive KQ dot product full depth everywhere 2010s-era transformers. Architectural innovation hasn't solved the problem. Turns out different architectures for approximating functions all form function approximators. The problem is in formulating the functions we want to approximate, not our spelling of the approximation engine!

> To evaluate generalizability, we conducted tests of GPT-5 (41), Claude Opus 4.1 (42), and Gemini 2.5 Pro (43) from 2025 September

The problem with empirical negative results on LLMs is that they can't rule out that the alleged deficiencies disappear with increased scale and the right fine-tuning. It's like saying my dog has trouble with subject-verb agreement, so meat brains are "fundamentally limited in their capacity for grammar".

I can accept that current LLMs (even latest generation) might exhibit cognitive gaps similar to those we see in humans with deficient executive function, I can't accept these gaps as evidence of fundamental limits of the transformer architecture. LLMs are universal function approximators. Executive function is a function. Yes, yes, it's well-known that transformers have a circuit complexity limit set by layer count and whatever. The limit disappears once you allow for autoregression. Nobody cares about the limits of AI inside a single forward pass.

I have high confidence that with the right sort of training, executive function gaps in LLM can be addressed. I'm not convinced that the problem is the architecture per se.