think of all the poor web devs trying to use multiple threads on top of asynchronous operations. wild.
Bun has an open PR adding shared-memory threads to JavaScriptCore
51–60 of 330 posts
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#52Earlier quoted context omitted.
> (actually I just checked again, and the PR has been closed by stalebot). Can you provide the link?
I, too, was curious to see it in practice. Here is the ticket opened by @retr0id: https://github.com/oven-sh/bun/issues/28030 And here is the swarm of bots / LLMs / agents that open, review and bikeshed the PR before it's closed by the stalebot: https://github.com/oven-sh/bun/pull/28031 It's hilarious. But also a little sad.
Yup, that's the one.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#53I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...
Yes, you did. And it's a good design. You even did the GC question justice.
My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things.
The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store.
JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming.
Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#54Earlier quoted context omitted.
IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
Adding concurrency to JavaScript definitely falls in the "complex enough" category So does basically any feature or optimization in a JS runtime
I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but for a person who is well familiar with the area there shouldn't exist areas they can't understand.
Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#55The 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 whatsoever
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
Perhaps then it would be better to not use tools of this level of complexity.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#56It’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.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#57One of the biggest things preventing software like SQL DB's from being written in TypeScript is the lack of proper threading. I genuinely think you could write a competitively-performant multi-threaded DB in Bun + TS if you had shared-heap threads and fast atomics/locking primitives.
You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.
Exactly. Nothing stops your writing a high-performance parallel database in TypeScript today. Given that runtimes and tooling are actually pretty good, I think TypeScript is actually a fine choice of language for the task.
The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space.
There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer.
If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database.
The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#58Earlier quoted context omitted.
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
Perhaps then it would be better to not use tools of this level of complexity.
how would you suggest we compile literally anything?
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#59Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#60Earlier quoted context omitted.
Adding concurrency to JavaScript definitely falls in the "complex enough" category So does basically any feature or optimization in a JS runtime
I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but f…
The solution to concurrency in JS is hard to understand and I would expect even hardened JSVM folks (me included) to be super confused by it