7 ms·

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-work/ https://webkit.org/b

by Jarred 3mo ago

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

aurareturn 3mo ago
While you're here, what's the status of the Rust rewrite and that blog post you promised to write?
- dsissitka 3mo ago
  It's a strange world. Rust rewrite: 6 days.[0] Blog post: 37 days and counting. [0] https://xcancel.com/jarredsumner/status/2060050578026189172 https://xcancel.com/jarredsumner/status/2060050578026189172
verandaguy 3mo ago
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 3mo ago
  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
  - verandaguy 3mo ago
    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 3mo ago
    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 3mo ago
      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 3mo ago
        > Post-ai you are ruining your code base if a pr is bad, i will reject it. that's the point of code review.
conartist6 3mo ago
I ran your proposed changes by TC39 and their initial reaction was simply "no". Is Bun the new IE6, then?
- conartist6 3mo ago
  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
- mhofman 3mo ago
  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.
kikimora 3mo ago
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.
solid_fuel 3mo ago
> 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 3mo ago
  The dogmatism on both ends of this argument grows tiresome.
  - port11 3mo ago
    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 3mo ago
      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 3mo ago
        def my_swe_percentile(best_agent_swe_percentile): return min(100, best_agent_swe_percentile * 1.25)
- ATMLOTTOBEER 3mo ago
  Tell your boss I’ll do your job for 20% of your pay
  - solid_fuel 3mo ago
    [flagged]
gr4vityWall 3mo ago
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.
duped 3mo ago
> 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 3mo ago
> the PR description is entirely Claude. Well, clearly more than just the description. Might as well be upfront about that.

by Jarred 3mo ago

aurareturn 3mo ago

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

dsissitka 3mo ago
It's a strange world. Rust rewrite: 6 days.[0] Blog post: 37 days and counting. [0] https://xcancel.com/jarredsumner/status/2060050578026189172 https://xcancel.com/jarredsumner/status/2060050578026189172

verandaguy 3mo ago

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 3mo ago
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
- verandaguy 3mo ago
  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 3mo ago
  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 3mo ago
    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 3mo ago
      > Post-ai you are ruining your code base if a pr is bad, i will reject it. that's the point of code review.

conartist6 3mo ago

I ran your proposed changes by TC39 and their initial reaction was simply "no". Is Bun the new IE6, then?

conartist6 3mo ago
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
mhofman 3mo ago
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.

kikimora 3mo ago

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.

solid_fuel 3mo ago

> 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 3mo ago
The dogmatism on both ends of this argument grows tiresome.
- port11 3mo ago
  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 3mo ago
    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 3mo ago
      def my_swe_percentile(best_agent_swe_percentile): return min(100, best_agent_swe_percentile * 1.25)
ATMLOTTOBEER 3mo ago
Tell your boss I’ll do your job for 20% of your pay
- solid_fuel 3mo ago
  [flagged]

gr4vityWall 3mo ago

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.

duped 3mo ago

> 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 3mo ago

> the PR description is entirely Claude. Well, clearly more than just the description. Might as well be upfront about that.