[Jarred]

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.

[solid_fuel]

> 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.

[amazingman]

The dogmatism on both ends of this argument grows tiresome.

[port11]

Indeed. And so is reading “x is the real thing. Real y, real z.” Plus all the other filler crap.

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.

[amazingman]

I don't find this problem any different than with human writers. Agents are verbose, sure, but I mostly find them providing far more useful information (in far less time) than your average (P80, really) SWE.

[nevertoolate]

  def my_swe_percentile(best_agent_swe_percentile):
      return min(100, best_agent_swe_percentile * 1.25)

[AlexeyBelov]

He's not even replying anywhere in this comment section. He doesn't care.

[solid_fuel]

Yeah, I know. Not a single comment in reply to any questions of substance in at least a month. I suspect he knows that his choices are indefensible, that's why he doesn't bother to defend them. Can't wait to read that blog post that's totally coming any day, though.

[MintPaw]

This is at odds with the idea that devs should take full accountability for LLM generated code.

He also didn't even say the code was generated by Claude, just the description, although a decent amount of the code probably was.

[solid_fuel]

This wouldn’t fly in college and it won’t fly for me. Claiming authorship means that you did the work. If you just prompt claude, then you authored the prompt. Not whatever claude slops out.

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.

[ATMLOTTOBEER]

Tell your boss I’ll do your job for 20% of your pay

[verandaguy]

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?

[rozularen]

How the heck do anyone in their sane mind justify 10-12k LoC PRs?

And Im not even going to get into OPs monster PR

[raincole]

It makes no sense. If a feature takes 10k loc to implement, it'd be a huge disservice for the reviewer and yourself to split it up into multiple PRs.

Your comment is equivalent to saying that no feature ever takes 10 loc to implement. It'd be quite ridiculous to say that aloud.

[1123581321]

Ideally, you could find pieces of that 10k that would also work as a standalone improvement to the app. I understand that team cultures can vary, but doing small features or refactors in service of a larger goal is nice, because while the reviewer knows you must be up to something, they can still approve your preparatory PRs as face value beneficial.

[charrondev]

I have some disagreement here. There are factors other than just code review to worry about when implementing changes, quite notably quality assurance.

It does not one any favours if your 10k LoC gets split in 5 changes that aren’t supposed to regress anything (but need to be validated not to) then 1 tiny on that brings things together.

Some features will be confusing for end users if you drip feed them. We had a whole host of changes recently overhauling our moderation system to be able to track and audit compliance with DSA and the key factor is ensuring the system makes sense to our users and that they can enable, have documentation and on-boarding materials for the changes in functionality and that it’s all QA tested.

In this case we did still review smaller chunks of code, we accumulated them into 1 large merge request at the end and merged it after QA.

[1123581321]

That’s a good point; it depends on the extent to which you can make either invisible changes or you can roll out improvements that don’t require coordinated communication.

QA should be happening either way.

[verandaguy]

It's easier to justify in a fast-moving greenfield code base with a verbose language... but I won't defend it. I've gotten better and I'm still getting better at breaking these things up.

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.

[jitl]

you can read a 10k pr in ~1-2hr. there’s nothing wrong with a 10k pr. i would rather review 1 10k pr than 10 1k prs or 50 200 line prs.

attitudes like this make it seem like computers are incomprehensible and we’re lucky to ever land code at all

[fizzynut]

10k in 2hrs is 1.5 lines of code per second for 2 hours straight without spending any time to make comments, think about what the code is doing, etc.

In pre-ai era that is just skimming and trusting the person who wrote it or the code changes are largely auto-generated or there exists an exceedingly simple test suite that is incredibly verbose.

Post-ai you are ruining your code base, I probably have to spend 3-5x longer reviewing ai generated code, the code they write tends to be too verbose, mediocre, filled with subtle bugs, adds unnecessary comments, etc. If someone gives me 10k loc pr it's a sure thing they've just let the ai run loose and I'd just tell them what they need to change in general terms instead of wasting days of my time reviewing junk.

[jitl]

> Post-ai you are ruining your code base

if a pr is bad, i will reject it. that's the point of code review.

[mahogany]

The point is that there is a 0% chance you can meaningfully understand the impact and consequences of what a 10k line change is doing in a couple hour review, so there’s no way for you to know if it’s “bad” in any sense other than it’s so awful that it’s obvious on a skim (which is what 10k lines in a couple hours is).

[rstuart4133]

> 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.

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.

[verandaguy]

I will say that a good solution to this starts before a line of code is written, and does require a PM or scrum master with a deft touch (ideally one who's been involved with the engineering side of a project for a while).

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.

[aurareturn]

While you're here, what's the status of the Rust rewrite and that blog post you promised to write?

[dsissitka]

It's a strange world.

Rust rewrite: 6 days.[0]

Blog post: 37 days and counting.

[0] https://xcancel.com/jarredsumner/status/2060050578026189172

[duped]

> 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.

[aarjaneiro]

> the PR description is entirely Claude.

Well, clearly more than just the description. Might as well be upfront about that.

[kikimora]

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.

[conartist6]

I ran your proposed changes by TC39 and their initial reaction was simply "no".

Is Bun the new IE6, then?

[mhofman]

To be clear, that was my opinion as a delegate, not the consensus of the committee, as that hasn't been formally discussed. That said, I believe other delegates share my opinion that shared memory concurrency needs to come with more constraints than what is suggested here, and while some delegates might be fine with it, I doubt any unconstrained shared memory concurrency would ever reach consensus if brought forward as a proposal. Currenntly the language spec is actually unclear on whether this is allowed for a compliant engine, and something we might want to update.

[conartist6]

I have respect for past you, whose accomplishments are incredible. Current you I think of like a circus performer. I trust you to get ooohs and aaahs from the AI-race spectators who don't know any better. I don't want someone who is primarily in showbiz within 10 fucking miles of my infrastructure though

[gr4vityWall]

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.