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

211–220 of 330 posts

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

#211

Post by kikimora »

pizlonator wrote: post #68
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…

I don’t understand the thread phobia Comparing it to nukes is a bit extreme, don’t you think?

I don’t think it is extreme. Imagine this is added to WebKit. Now I have a new question to answer - can I use library X across multiple threads? How do I know it does not have a little cache inside which breaks if I call it from multiple threads?

Another issue is lack of memory model (sorry if ai missed it) which means memory updates will be published to threads differently on different architectures.

And then an obvious problem of mixing async with locks - never ends good.

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

#212

Post by raincole »

rozularen wrote: post #198
verandaguy wrote: post #195

Earlier quoted context omitted.

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…

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

It makes no sense. If a feature takes 10k loc to implement, it'd be a huge disservice for the reviewer and yourself to split it up into multiple PRs.

Your comment is equivalent to saying that no feature ever takes 10 loc to implement. It'd be quite ridiculous to say that aloud.

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

#213

Post by kikimora »

jitl wrote: post #158
gwbas1c wrote: post #120

Back when Node was the new kid on the block, the single-threaded async model was justified by pointing out that the major challenge with multithreading was shared memory. It's one of the strong points of the language / environment, because you never have to worry that some callback will run on another thread. Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become…

yes, all of node.js is built on such operations. what do you think is happening when you `await fs.promises.readFile(name, 'utf8')`? it dispatches a libuv thread to read the file you want, and resolve the promise when the background thread has completed the operation.

Except there is often no background thread but async IO.

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

#215

Post by deaddodo »

adamddev1 wrote: post #156
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.

Everyone's excited about using AI to make their quick end products. But no-one wants to actually build on or rely on vibe-coded frameworks, languages, or tools.

I think AI is fine, the problem is what you mentioned: vibe coding.

Have AI do work for you, it’s certainly faster in most cases. But just know exactly what it’s generating and building before putting it into production. That’s not some massive bar to surpass.

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

#216

Post by kikimora »

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.

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

#217

Post by afavour »

tyre wrote: post #182
afavour wrote: post #149

Earlier quoted context omitted.

I’m amazed folks ever migrated to it at a workplace level TBH. It’s a VC funded runtime, something was always going to happen to it. Node is boring but its governance and ownership is clear.

Well, it was (is?) significantly easier to use, faster, the team behind it is fantastic, and generally had enough compatibility to run the projects I needed it to. When it’s enough of a drop-in replacement, that’s more than good enough. As long as we’re not adding a hundred bun-specific things, it’s not terribly difficult to back out of, either. Kind of a no-brainer.

Faster I get. But easier to use?

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

#218

Post by fizzynut »

jitl wrote: post #207
rozularen wrote: post #198

Earlier quoted context omitted.

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

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

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.

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

#219

Post by ozgrakkurt »

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.

This sounds pretty insane if you wrote any database code that needs to care about memory management at all

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

#220

Post by diatone »

jhack wrote: post #157
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.

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

First word of second sentence:

> Stability

ie: lack of volatility, ie: integrity, ie: I know it does what it says and don’t have to second guess that.

Post reply on HN