alt Hacker NewsI’m the author of this PR.
This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-wo.... I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go.
The title should be changed to clarify that it’s a PR to Bun’s JavaScriptCore fork and not the upstream WebKit.
This PR is scarier to merge than Bun’s Rust rewrite PR. There are a good number of benchmarks/stress tests, unit tests, and also TSAN runs and security scanner runs, but this is a more complex change than the Rust rewrite (yes, really). I’m also worried about syncing with upstream - today the “fork” is mostly a bunch of patches, but with this PR, changes to the JIT need to be reviewed for behavior when multiple threads are in use. Our best bet for this to move forward is figuring out a way for some constrained version to be upstreamed into WebKit proper, if that makes sense and if they’re interested.
And yes, the PR description is entirely Claude.
Replies
I've seen the Bun Zig->Rust MR a few weeks ago when it was current. Now I'm seeing this, and I have to ask, since you're here:
Is there no way to make this changeset smaller?
At work, I've usually written large patches. I used to be worse at it. I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually process.
For perspective, my "large patches" were PRs on the order of 10-12kLOC for relatively big features. I consider those to be on the upper end of what is reasonably reviewable by a small, non-dedicated team, and towards the upper limit of the kind of PR where I can speak for nearly every line of code, what it does, and why it's there.
On the other hand, now, LLMs are part of the equation, and they can (and often do) write code in insane volumes. They arguably tend towards extreme verbosity, without even talking about docs/markdown files. While LLMs are part of the workflow, my company, and those my friends work at, have all instituted policies of the developer attaching their name to the code ultimately being responsible for the output (which IMO is a lazy strategy, but I can't think of a much better one under the circumstances).
I cannot, personally, fathom how you can stand behind a single changeset spanning 2000 files and a quarter-million lines of diff. Do you consider this sustainable?
At this point the code bases are very quickly getting away from us in the open source community and even in proprietary code bases, and these are important code bases. Often very complex, often legacy. Who ultimately still owns these? Who's really going to be accountable if things go wrong?
I ran your proposed changes by TC39 and their initial reaction was simply "no".
Is Bun the new IE6, then?
While you're here, what's the status of the Rust rewrite and that blog post you promised to write?
If the goal of this change is to:
>mostly share read-heavy graphs and coordinate through a few hot objects, which is what Lock/Atomics are for.
Then it is a clear overkill to me. I’d rather built an in-memory DB on top of shared array buffer. Would work almost as good as an object graph but does not require a full system overhaul.