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

261–270 of 330 posts

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

#261

Post by curtisblaine »

kikimora wrote: post #216
curtisblaine wrote: post #131

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:/…

This is from PR: v1 collects synchronous and stop-the-world Go build performant web app that has stop-the-world all the time.

You bypass GC by allocating pools of array buffers at the cost of low-level memory management.

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

#262

Post by sph »

cavoirom wrote: post #259
xlii wrote: post #75

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

I agree with you. Human is a forgetful race, they just unlearned the zlib lesson. Edit: fixed typos.

Do you mean XZ?

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

#263

Post by curtisblaine »

quotemstr wrote: post #147
curtisblaine wrote: post #142

Earlier quoted context omitted.

Worth noting that javascript has had workers, shared memory and atomics for years and that you can use them today. Look at this guy writing a lockless allocator: https://greenvitriol.com/posts/lockless-allocator The only difference in this PR is that it makes threads light (workers are fat because they carry a whole v8 instance with them) and it makes shared memory default with light threads (now you need to pass a s…

There's a difference between 1) having a shared-everything heap and 2) having a separate, obscure facility (which practically nobody uses) for building a special data-only portal to shared memory. #1 normalizes the mutex. #2 doesn't. I have strong opinions on the superiority of #2 to #1 because I've dealt with endless bugs caused by people who think they can handle #1 and can't. Reasoning about complex memory order r…

#2 is very much used in high performance web apps, whenever you can't afford the overhead of message passing. I agree it's a specialized tool and normally you don't need it, but it's a misrepresentation to say "it's an obscure feature that almost nobody uses". If you do webGL, for example, you almost invariably end up using shared array buffers.

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

#264

Post by sph »

weird-eye-issue wrote: post #249
solid_fuel wrote: post #230

Earlier quoted context omitted.

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

[flagged]

Why do you feel so threatened that a person is ‘not impressed’ with a thing? Is it a moral fault to have doubts and concerns now?

‘Quick! Get him! We have found a skeptic’ - sounds like a cult to me.

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

#265

Post by simonra »

kennywinker wrote: post #250
pjjpo wrote: post #241

Earlier quoted context omitted.

I think this is precisely why I don't mind it that much. I can't audit a huge codebase like a JavaScript runtime, whether the code is by a human from scratch or not. I just have to trust it as a black box. I've seen LLMs produce terrible code indeed, but I have also seen humans produce terrible code. I haven't dug in to JS runtimes specifically but have read plenty of code in openjdk and cpython - there are many poin…

The difference is you can evaluate a small bit of the output of a human or a team of humans and expect all their other code to be roughly in the same ballpark of quality. An LLM can’t be trusted to produce code and make higher level project structure choices of the same quality at all times, because it can’t be trusted at all - trust is for deterministic systems. But still it begs us to trust it. Every prompt that yi…

As long as the odds are good enough (and/or you know the distribution), there is nothing wrong in relying on and profiting from stochastic systems despite not every outcome being positive. What matters is the sum of outcomes, not the individual ones.

It means you need to be able to handle failure, but you should always have a good grip on how to correct if you intend to set things out in the real world which messes up everything always anyways.

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

#266

Post by talldeck »

fg137 wrote: post #47
Retr0id wrote: post #10

Earlier quoted context omitted.

The PR is against bun's fork of WebKit, not upstream.

The title is of this post is definitely confusing if not misleading.

Besides, the title should probably have referred to it as "a giant open PR" or something, because I don't think what the submission is trying to focus on is the feature itself.

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

#267

Post by nasretdinov »

jerf wrote: post #67
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. P…

Yeah I kinda agree about Go. CockroachDB didn't catch on nearly as much as it should, and I wonder how much it has to do with the fact that optimising code in Go (both in terms of memory usage and performance) is just much harder than C

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

#268

Post by mingqiz »

cmeacham98 wrote: post #179
jhack wrote: post #157

Earlier quoted context omitted.

"Even it that'd be the best code and design in the world, I won't use it. I don't trust it." Nothing about this sentence makes sense. What don't you trust about code you can see and audit yourself? What's untrustworthy about "the best code and design in the world"?

I don't have the time to audit all the code in a JavaScript runtime myself, so I am forced to make assumptions about the quality of the code based on my trust of the authors. Additionally, even if the code is good today, I am trusting their process will produce good code tomorrow (as migrating to/from bun has a non-trivial cost). A single person approving the code of an LLM is not such a process with today's technolo…

I honestly trust code reviewed by llms multiple rounds more than human reviewed code. Here is the thing. I don't know the human who wrote the code but i am familiar with the model they use, which might already be better than many human.

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

#269

Post by kennywinker »

simonra wrote: post #265
kennywinker wrote: post #250

Earlier quoted context omitted.

The difference is you can evaluate a small bit of the output of a human or a team of humans and expect all their other code to be roughly in the same ballpark of quality. An LLM can’t be trusted to produce code and make higher level project structure choices of the same quality at all times, because it can’t be trusted at all - trust is for deterministic systems. But still it begs us to trust it. Every prompt that yi…

As long as the odds are good enough (and/or you know the distribution), there is nothing wrong in relying on and profiting from stochastic systems despite not every outcome being positive. What matters is the sum of outcomes, not the individual ones. It means you need to be able to handle failure, but you should always have a good grip on how to correct if you intend to set things out in the real world which messes u…

Sure, but that’s not how most llm coding is done, because if a human has to carefully supervise the llm then what’s the point - might as well write it yourself.

Add to that, we’re very good at anthropomorphizing, and very bad at supervising systems that are usually right. Makes for a mess.

Oh, and this all relies on the ai providers not changing things up behind the scenes and feeding you a dumber model sometimes.

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

#270

Post by solid_fuel »

weird-eye-issue wrote: post #249
solid_fuel wrote: post #230

Earlier quoted context omitted.

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

[flagged]

[dead]
Post reply on HN