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

201–210 of 330 posts

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

#201

Post by verandaguy »

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's easier to justify in a fast-moving greenfield code base with a verbose language... but I won't defend it. I've gotten better and I'm still getting better at breaking these things up.

I brought the 10-12kLOC PR up as an example supporting my point of view. I don't encourage the behaviour. Most of my PRs these days fall under the 1500LoC mark, tops -- maybe a bit more if it's a tricky component that needs a ton of tests.

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

#202

Post by jitl »

stephen wrote: post #177
jitl wrote: post #166

Earlier quoted context omitted.

if there was a thingy that compiled JS to a 10mb native executable with shared heap multithreading, im sure we'd use it. however, no one has invented such a thing. until this pr.

Right! That's why I think this is an exciting development. I assume everyone is downvoting me for "liking LLM slop", but really I just like the competition that "this is possible!" And would love a slop/non-slop/whatever version in Node/v8. Someday!

same. ts with thread + struct would be a killer language.

i pray anthropic buys roblox to get pizlo to actually land this

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

#203

Post by marshray »

Jarred wrote: post #194
unknownfuture wrote: post #192

Earlier quoted context omitted.

It's called "mileage". This new codebase doesn't have any. Who knows what gremlins lurk in some of its darker corners.

> new codebase doesn’t have any Claude Code & Prisma use it as of last week.

That comment had me reaching for the skull emoji.

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

#204

Post by maddmann »

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.

What about Claude code?

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

#205

Post by JCTheDenthog »

root_axis wrote: post #187
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

We've repeatedly seen that these test-driven LLM rewrites consistently produce absolute garbage.

Got any specific examples? I believe you, I'd just like some concrete examples to show my coworkers.

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

#206

Post by jitl »

anematode wrote: post #169
jitl wrote: post #168

Earlier quoted context omitted.

yes i love to use a language runtime within another language runtime for a sweet sweet 30% performance penalty

Why the snark? wasmtime is a (pretty popular) Rust project which uses a JIT, demonstrating that it's not incompatible with Rust. Obviously a proper VM wouldn't depend on wasmtime, but implement its own JIT and paraphernalia.

fair. i guess i used “rust” in collective noun sense for “rust the ecosystem and community”; from my armchair experience there’s a big contingent of that community that abhors unsafe and software that uses it, and it’s that community/ecosystem aspect that prohibits unsafe since of course the language and compiler support it just fine.

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

#207

Post by jitl »

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

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

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

#208

Post by kikimora »

Jarred wrote: post #190

I’m the author of this PR. This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-wo... . I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go. The titl…

If the goal of this change is to:

>mostly share read-heavy graphs and coordinate through a few hot objects, which is what Lock/Atomics are for.

Then it is a clear overkill to me. I’d rather built an in-memory DB on top of shared array buffer. Would work almost as good as an object graph but does not require a full system overhaul.

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

#209

Post by JamesSwift »

Ive said many times in my day-to-day convos around AI that Ive come to realize more and more that AI is a solo endeavor. Its very difficult to scale things to more people if you are trying to use AI for more than just speeding yourself up.

AI is the epitome of the saying "if you want to go fast, go alone". This PR and the rust rewrite are incredible in scale and ambition. I still think theres a middle ground though of traditional committee-driven design with AI-driven iteration and POCs.

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

#210

Post by marshray »

murderfs wrote: post #151
moomin wrote: post #136

Look, 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 thi…

I don't think AI is particularly worse at multi-threading code than humans are: humans are notoriously bad at it. I've had reasonably good success with telling Claude and Gemini to go into a codebase, insert clang -Wthread-safety annotations, fix any issues it finds, and refactor code that isn't amenable to the annotations to make it possible.

But there are any number of humans who will tell you that humans are bad at multithreading the codes and all but the smallest codebases are headed for heisenbug deadlock city if you do things like they told you to in that Introduction to OOP with JavaTM book.

But is Claude going to tell you "No, dear user, this project is going to follow an excessively simple and sub-optimal locking regime because experience shows that it is easier to write code than it is to reason about its exponentially-growing complexity" ?

Post reply on HN