Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun has an open PR adding shared-memory threads to JavaScriptCore

github.com

Post reply on HN
Print view View original

61–70 of 330 posts

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#61

Post by nasretdinov »

norir wrote: post #55
pizlonator wrote: post #26

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

I think LLVM is a perfect example of what happens when it's too complicated: it's slow, it's bug-ridden when you stray away from the beaten path (e.g. Rust hits bugs in LLVM like this one https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... ), and it's really hard to use and understand.

It's obviously not useless because of that, but it's a great example of what happens when you cannot fully control the implementation complexity

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#62

Post by nasretdinov »

spankalee wrote: post #59
norir wrote: post #55

Earlier quoted context omitted.

Perhaps then it would be better to not use tools of this level of complexity.

So don't use compilers at all?

Compilers aren't made equal either. E.g. compare Visual Studio C++.NET compiler and something like Go. And Go isn't that simple either to be fair

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#64

Post by hexasquid »

quotemstr wrote: post #53
pizlonator wrote: post #2

I 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 memor…

This is consistent with the endless contempt people have had for JavaScript and those that use it.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#66

Post by 12_throw_away »

quotemstr wrote: post #39

I 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…

In contrast, I don't know that much about VMs.

But if you're making a big fundamental change to a system, I do know that it shouldn't start with a single "+279,276 -4,272" PR. It starts with a small patch with the core of the change so that everyone can understand what it does and how it works. (I mean, ideally, a change like this starts with documentation, discussion, diagrams, surveys of existing implementations, etc, before you start writing code)

You don't cram everything into a single 270K line PR, even (especially) with an LLM, unless you specifically don't want anyone else to look too closely at what you did.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#67

Post by jerf »

gavinray wrote: post #8

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

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

Not likely. Databases that attain any significant use in the field end up getting optimized to the n'th degree because they're the bottleneck of the entire system of every system they get put into. Javascript runs on the "5-10x slower than C" language tier. Personally I think even picking Go, in the "2x slower than C" tier, is a huge mistake, though a few people seem to be doing OK with it. I don't think you can call it "competitive" when your C++ or Rust competition is consuming a factor of magnitude less resources.

WASM DBs, maybe, especially as it continues to mature. Not Javascript.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#68

Post by pizlonator »

quotemstr wrote: post #53
pizlonator wrote: post #2

I 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 memor…

I don’t understand the thread phobia

Comparing it to nukes is a bit extreme, don’t you think?

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#69

Post by doodlesdev »

fg137 wrote: post #46
asxndu wrote: post #17

I am shocked by how good and comprehensive the bun docs & ecosystem is. Its so well contained I never need to look outside its ecosystem for basic components. It's a true "Batteries Included" runtime.

Yet I rarely hear about it being used in production systems and replacing Node.js.

It famously is extremely memory leaky, with the core team having no idea how to fix it. With the new AI-automated unsafe Rust migration, this piece of slop may never actually become production-ready.

Re: Bun has an open PR adding shared-memory threads to JavaScriptCore

#70

Post by pizlonator »

hexasquid wrote: post #64
quotemstr wrote: post #53

Earlier quoted context omitted.

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 memor…

This is consistent with the endless contempt people have had for JavaScript and those that use it.

Yeah I don’t get that either

It’s a super successful language

Post reply on HN