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

141–150 of 330 posts

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

#141

Post by re-thc »

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.

> And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package.

Bun is mostly AI written and AI reviewed at this point (all automated).

The 1-person is luxury.

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

#142

Post by curtisblaine »

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…

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 shared array buffer first).

Javascript is probably not your first language, I get it, but it has had "the siren song of a mutex" for years now. What really surprises me and I can't explain is why you went and took time to express such strong opinions on something that you obviously don't even know or use that well.

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

#143

Post by zarzavat »

okeuro49 wrote: post #117
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.

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

Just think about what "tests pass" means for a rewrite. If you rewrite from language A to language B then any unit tests have to be rewritten during the rewrite.

So either "tests pass" does not include unit tests or unit tests were rewritten probably by the same AI that is doing the rewrite!

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

#144

Post by mahogany »

torben-friis wrote: post #50

>Scalability, measured (the honest section) Ugh.

The entire PR description is filled with LLMisms. I find this style so hard to read, it’s almost nauseating these days. My eyes start to glaze over and I stop reading pretty quickly after. I’m having to deal with this a lot at work these days unfortunately. I mean, did anyone even read or verify this output? When I read this type of stuff, I have the nagging suspicion that I am the proofreader and I have to do the verification myself. At that point, what are we even doing? I can generate Claude output myself…

I know I’m being overly dramatic but this sort of thing feels so wrong and inhuman(?) to me for some reason.

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

#145

Post by theturtletalks »

okeuro49 wrote: post #117
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.

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

[dead]

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

#146

Post by queenkjuul »

poly2it wrote: post #104
torben-friis wrote: post #50

>Scalability, measured (the honest section) Ugh.

I can't stand Claude's "honesty". Anthropic should hire some writers and linguists to make the output a bit more bearable. It's mentally taxing to read this type of dull text for hours every day.

I just can't do it. I barely skim Claude PR reviews and have no qualms asking someone to summarize in their own words if they've sent me two pages of Claude slop

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

#147

Post by quotemstr »

curtisblaine wrote: post #142
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…

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 rules and thread interleaving is extremely difficult for both humans and AIs. That's why we abstract over raw threads with actors, STM, fork/join facilities, and (my favorite) structured cooperative concurrency. It's not a knock against anyone's skill to point out that EVERYONE gets concurrency wrong and we need guardrails on top.

That said, let's be honest: the JS ecosystem has a culture that'll make #1 worse than it usually is. There's a certain combination of insularity and lack of restraint I've observed in the JavaScript world that prompts its members to re-learn the hard way all the painful lessons in software history.

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

#148

Post by afavour »

thedelanyo wrote: post #119
Waterluvian wrote: post #73

Earlier quoted context omitted.

I think with ES6 and newer things really cleaned up and now we’re left with avoidable ugly parts, of which every language has. Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting. Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept…

> I’m just hoping one day browsers will accept TS the same way. Wouldn't that be a direct kill of JS?

TS is JS just with stuff on top so it can’t really ever kill JS. The way Node does it is to just ignore the type notations in a TS file, making it valid JS. Does mean you can’t use things like enums but worth the price.

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

#149

Post by afavour »

egorfine wrote: post #100
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.

Yeah, I have prepared our company software for migration back to node. I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.

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.

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

#150

Post by blcknight »

applfanboysbgon wrote: post #132
okeuro49 wrote: post #117

Earlier 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

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

I hear a lot of complaints about bun but nothing concrete about what broke in the migration.

You are also assuming one prompt, and then arguing against your assumptions with zero evidence. It is lazy arm chair criticism.

Post reply on HN