To all the people saying "it's dangerous to add concurrency to javascript", javascript has already workers, shared array buffers and atomics. It's entirely possible today to start two or more workers, pass a shared array buffer via a message and then write concurrently on the same buffer forfeiting message passing and synchronizing only using atomics. You can even do lock less data structures, see for example https://greenvitriol.com/posts/lockless-allocator. That's what you do when you write high performance Web apps.
This proposal only adds lightweight threads sharing memory by default, but it's by no means the first and only way to do low level concurrency with javascript.
Bun has an open PR adding shared-memory threads to JavaScriptCore
131–140 of 330 posts
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#132I wonder if I'm the only one for whom the bun project vanished completely. In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package. Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
> quite a lot of analysis went into the rewrite
Literally just prompted for an LLM to review it and asked for a fancy presentation. That is not "quite a lot of analysis". That is anything but.
> If the tests pass, then why not accept the rewrite?
Because (1) tests passing are absolutely not a guarantee that no regressions were introduced in a change, and (2) even if they were, those tests are the result of thousands of hours of human labour, which is all well and good for the codebase as it currently exists, but who is going to be writing the tests for the 1m loc repo of unread code in the future? Unless you've proven that specifically LLM-generated tests can prevent all possible regressions, you're condemning the future of the project because nobody will be able to continue writing robust tests.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#133I wonder if I'm the only one for whom the bun project vanished completely. In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package. Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
Given that even the unsafe audit article appears to be written by AI that doesn't seem like much thought to me.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#134Earlier quoted context omitted.
It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
Given that even the unsafe audit article appears to be written by AI that doesn't seem like much thought to me.
It explicitly says "AI-generated" at the top, so there's no doubt about it.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#135The 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
My Elm code base was virtually bug free. My current python code base is riddled with small bugs. Some designs makes it easy to trust your code. Some make it die by a thousand paper cuts.
Big llm rewrites I fear lead to the latter.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#136Look, 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.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#137I know a thing or two about VMs. Reading this post, I thought to myself "No way it was this easy. No performance hit in the single threaded case? No way". I was right. Buried in the middle of the post is this tidbit: > v1 collects synchronous and stop-the-world Ah, there it is! I knew it! Parallel garbage collection is a very hard problem. Years of experience and subtle implementation are required to get something li…
I sometimes wonder if full GC is really worth it. For a lot of applications some compile time analysis + refcounting is close enough, and for some others arenas (per frame rendered, per request served, etc) are as fast as a GC to allocate and faster than malloc to free. Could we make the rest a compile error and save most people most of the time a lot of pain?
GC is worth it. What you're proposing is a false economy.
In addition to lifetime management, GC gives you compaction, pointer compression, and fast bump-pointer allocation that doesn't depend on being able to represent your lifetimes as nested arenas.
Modern GC is excellent. Replacing it with manual allocation isn't better, even with guardrails: reference counting is expensive, atomic reference counting doubly so, and free() itself is very far from free.
Sure, you can restrict lifetime shapes, but when you do that, people switch to allocating out of arrays and using indices as pointers, so you're right back where you started with respect to lifetime management.
So what are you saving? You're just replacing the high-performance concurrent mark/sweep microsecond-pause GC someone has written and debugged for you for free with custom convoluted logic that'll probably leak and run slower besides. Why would anyone want this trade?
The elevation of manual memory management to standard performance practice is a generational mistake this industry is making.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#138Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#139I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...
In case anyone missed it, this PR is based on that:
> This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!".