Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Putting on my tinfoil hat. Did Anthropic even buy Bun because they actually use it or was it just an excuse to lob ridiculous PRs at things with at least a little bit of credibility behind them. Their way of trying to set a precedent for accepting AI code into bigger open source projects.by roblh
- The author has huge online following, and influence over developers. I don't doubt the author is genuinely interested in this, but the employer definitely is supporting this too.by rzmmm
- I like how the page is actually struggling to load due to the sheer amount of bot activity on the PR.
On a completely unrelated note, I wonder why Github is always down. Real mystery there.
by bakugo - Back when Node was the new kid on the block, the single-threaded async model was justified by pointing out that the major challenge with multithreading was shared memory. It's one of the strong points of the language / environment, because you never have to worry that some callback will run on another thread.
Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become very thread-like with async/await syntax. Multithreaded code in this context only helps with CPU-bound operations; but if I was doing something CPU-bound, I'd probably choose a different language.
One thing I wonder, does Bun (or Node) have a way to call into native code on another thread, but still keep single-threaded once back in JavaScript?
by gwbas1c - yes, all of node.js is built on such operations. what do you think is happening when you `await fs.promises.readFile(name, 'utf8')`? it dispatches a libuv thread to read the file you want, and resolve the promise when the background thread has completed the operation.by jitl
- Is there a human-authored description of the PR anywhere?
How are there not race conditions all over the place?
by Retr0id - It's substantially based on my design, read the blog post I wrote (linked in another comment here)
It's a very complex thing, but not impossible. I'm very impressed that any LLM can do this
by pizlonator - It’s pretty incredible to me that a mammoth change like this is possible to prototype now using LLMs.
It makes me wonder how much of our software stack will become more malleable to big ideas and experiments in the future, like Filip’s idea here. Even if you don’t want to merge the code, it’s still an incredible existence proof that something like this could work.
by sothatsit - Bingo. Dozen LLM-prototypes and then a manmade final patch which is merged.by rzmmm
- >Scalability, measured (the honest section)
Ugh.
by torben-friis - almost spit out my drink!by greenchair
- Yes, that's the smoking gun!by rbonvall
- I can't stand Claude's "honesty". Anthropic should hire some writers and linguists to make the output a bit more bearable. It's mentally taxing to read this type of dull text for hours every day.by poly2it
- The entire PR description is filled with LLMisms. I find this style so hard to read, it’s almost nauseating these days. My eyes start to glaze over and I stop reading pretty quickly after. I’m having to deal with this a lot at work these days unfortunately. I mean, did anyone even read or verify this output? When I read this type of stuff, I have the nagging suspicion that I am the proofreader and I have to do the verification myself. At that point, what are we even doing? I can generate Claude output myself…
I know I’m being overly dramatic but this sort of thing feels so wrong and inhuman(?) to me for some reason.
by mahogany - This em-dash stricken PR is yet more evidence that the bun project has AI psychosis.
The most important feature for a language runtime is reliability. It's the foundation, it should be boring. I need to know that the foundation is stable so that I can control the reliability of whatever's built on top.
AIs hallucinating a multithreaded JSC is not boring, it's scary.
by zarzavat - The code needs to be not in the state of "no obvious bugs", but "obviously no bugs". Especially the programming language runtime. Otherwise there is no hope you can sustain any development whatsoeverby nasretdinov
- Won’t happen unless the thing is implemented in lean4.by baq
- No language runtime is ever in a state of "obviously no bugs".
Good luck demanding that of anything of JSC's or LLVM's complexity
by pizlonator - Look, I’m not an AI hater, but AI is… not great at multi-threading code. And having it analyse multi-threaded code proves nothing because… it’s not good at multi-threaded code. This isn’t entirely shocking because I’m not good at it either and need to write in some very particular ways to have even a hope of being correct. But basically, unless it was written by a genuine expert, I wouldn’t want to even glance at this PR. And it wasn’t.by moomin
- I don't think AI is particularly worse at multi-threading code than humans are: humans are notoriously bad at it. I've had reasonably good success with telling Claude and Gemini to go into a codebase, insert clang -Wthread-safety annotations, fix any issues it finds, and refactor code that isn't amenable to the annotations to make it possible.by murderfs
- I’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.
by Jarred - Is it possible to merge it, but keep it disabled by default? This could allow users to play with it on Bun while maintaining the expected behavior of JSC.
Maybe a separate build could work too.
by gr4vityWall - I ran your proposed changes by TC39 and their initial reaction was simply "no".
Is Bun the new IE6, then?
by conartist6 - 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.
by kikimora - > the PR description is entirely Claude.
Well, clearly more than just the description. Might as well be upfront about that.
by aarjaneiro - > the PR description is entirely Claude
You should be embarrassed to admit this, let alone do it. The lack of shame people have these days is gross.
by duped - While you're here, what's the status of the Rust rewrite and that blog post you promised to write?by aurareturn
- 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?
by verandaguy - > I’m the author of this PR.
> And yes, the PR description is entirely Claude.
If you didn't write it, you're not the author. That's how it works, man.
I would also love to read that blog post about the Rust rewrite, when you get it published.
by solid_fuel - I knew it was possible :-)
https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...
by pizlonator