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.
> 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.
If you can command a model, you can tell it to write without fluff.
The amount of effort to ask an LLM to do work is massively lower than the effort for a human to review it.
He also didn't even say the code was generated by Claude, just the description, although a decent amount of the code probably was.
Jarred should be putting the prompts in github, since that’s the only original work involved.
And to be clear, I don’t think that being responsible for what is produced and claiming authorship are the same thing. I do agree that Devs are responsible for what they ship.
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?
And Im not even going to get into OPs monster PR
Your comment is equivalent to saying that no feature ever takes 10 loc to implement. It'd be quite ridiculous to say that aloud.
I brought the 10-12kLOC PR up as an example supporting my point of view. I don't encourage the behaviour. Most of my PRs these days fall under the 1500LoC mark, tops -- maybe a bit more if it's a tricky component that needs a ton of tests.
attitudes like this make it seem like computers are incomprehensible and we’re lucky to ever land code at all
I struggle with the same issue. In my experience you can't reduce the total number of lines. If the feature took 10k or 15k loc to deliver it, you aren't going to be able to reduce that meaningfully.
You can usually break it into stacked series of commits. New code can be split up into stand alone modules, which all compile and pass their unit tests. They could even be shipped, although they wouldn't be used because the changes to the UI are always the last piece of the puzzle. If you are refactoring, you can usually find a way to split the refactor into smaller steps, each building on the previous one. That is almost certainly possible in this case.
The issue with both approaches is while you can review each step independently, what you miss by looking at just that commit is the motivation for doing it. You can only get that from the big picture, and to get the big picture you need the entire 10k or 15k loc available.
That means you have to push the entire series of commits. If you want to make it plain they are individually reviewable you push them as stacked PRs. Either way, it's a 15k loc push.
I don't see a way out of that for the same reason neither bottom up nor top down design works on their own. You have two edges - the upper (often the UI), and the lower (the OS, standard library - things you have to use to get anything done). You work from both edges simultaneously, each working towards the other, hopefully so that when they meet in the middle and the two fit together nicely. The point is, you have to review like that too. You can't just look at how neatly the blocks are stacked on the foundations, you have to evaluate if they are taking the best route to the destination. The review can fail in both ways - the UI can be beautiful but it stands on a mess, or the code could have built up a beautiful series of abstractions that bubble through to the top level and ultimately confuse the end user. So you have to review the code from both perspectives, and to do that you ultimately need to get your head around all 15k loc.
This means a reviewer demanding they be spoon fed a few thousand lines of code at a time is being as unreasonable as the person delivering 15k loc in one commit. They are demanding a simple solution to their problem, and it is wrong. They should be demanding all 15k loc be delivered in the form the author intends to ship, but split into digestible commits that clearly explain the path and reasoning taken between the top and bottom edges, so both the top and bottom level designs are plainly visible.
What happens when I do that is I get into fights over forced pushes. Everyone hates them, and for good reason. They asked for a simple change in their review, and what they want to see is a small commit reflecting their request. Hiding that by doing a rebase is met with howls of pain: "no forced pushes!". So you insert your commit reflecting just the change they asked for into the stack of commits the large feature necessitated. Doing that rebases every commit that depends on it, of course. You push the result and are treated with a chorus of "NO FORCED PUSHES".
Forbidding all forced pushes makes about as much sense as forbidding a 15k loc change, even through its well-structured into commits. It makes me wonder if unis bother to teach modern software engineering practices.
Working with them, the scope can be brought down, sometimes, though this obviously depends a lot on externalities like who the customer is and how much flex they're comfortable adding to the timeline, since that often becomes a factor.
Part of becoming a more mature developer involves being able to navigate these situations with PMs better, and dealing with the frustrations that can often bring (in my experience). I'm still working my way up this side of the job. Historically this stuff has been managed up really thoroughly by my immediate manager (a factor of both the manager's working style, the work being done, and the broader company structure), but my current company structure means that I have to get better at this stuff a lot more actively.
Is Bun the new IE6, then?
Rust rewrite: 6 days.[0]
Blog post: 37 days and counting.
[0] https://xcancel.com/jarredsumner/status/2060050578026189172
>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.
