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

121–130 of 330 posts

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

#121

Post by hedgehog »

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…

I sometimes wonder if full GC is really worth it. For a lot of applications some compile time analysis + refcounting is close enough, and for some others arenas (per frame rendered, per request served, etc) are as fast as a GC to allocate and faster than malloc to free. Could we make the rest a compile error and save most people most of the time a lot of pain?

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

#122

Post by rzmmm »

sothatsit wrote: post #56

It’s pretty incredible to me that a mammoth change like this is possible to prototype now using LLMs. It makes me wonder how much of our software stack will become more malleable to big ideas and experiments in the future, like Filip’s idea here. Even if you don’t want to merge the code, it’s still an incredible existence proof that something like this could work.

Bingo. Dozen LLM-prototypes and then a manmade final patch which is merged.

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

#124

Post by curtisblaine »

JCTheDenthog wrote: post #95
hexasquid wrote: post #65

Earlier quoted context omitted.

Standard contempt for web developers.

[flagged]

Worth noting it's not web devs pushing for React in the Windows start menu. It's PMs looking at the problem and concluding React is the least painful way to solve it (correctly or incorrectly, but I doubt they optimize for the same measurements you do).

Ink (the React renderer) in Claude code, on the other hand, makes a lot of sense for interactive CLIs where you want to componentize your menus and dialogs. Actually not using a component framework normally ends up in state / render chaos.

Re: mayflies debating politics: React has been there for 13 years, and while the interface has shifted a couple of times (object factories to classes to functions), the main idea has always been really simple and really stable: isolated declarative components that can optionally have state and side effects. Many other popular frameworks have come and gone in the meantime.

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

#126

Post by dgellow »

Delgan wrote: post #33
Aurornis wrote: post #27

Earlier quoted context omitted.

> (actually I just checked again, and the PR has been closed by stalebot). Can you provide the link?

I, too, was curious to see it in practice. Here is the ticket opened by @retr0id: https://github.com/oven-sh/bun/issues/28030 And here is the swarm of bots / LLMs / agents that open, review and bikeshed the PR before it's closed by the stalebot: https://github.com/oven-sh/bun/pull/28031 It's hilarious. But also a little sad.

Ok, you didn’t lie, it’s extremely funny, the stalebot at the end is such a good punchline!

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

#127

Post by dgellow »

egorfine wrote: post #112
fg137 wrote: post #46

Earlier quoted context omitted.

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

I run it in production for multiple systems. Ready to migrate back to node once the slop version is out.

Why not deno?

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

#128

Post by Yoric »

MuffinFlavored wrote: post #103
Yoric wrote: post #36

Earlier quoted context omitted.

I just wrote an internal report in my company. My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system. We'll see in which direction the CTO takes this. My bet is not on quality.

The company I work for, the code Opus 4.8 is able to generate, is higher quality than what was left behind by 10+ years of contractors that have come and gone.

I understand that some developers produce very poor code. Maybe in some companies it's the norm. Luckily for me, I've seldom worked alongside such developers.

In my company, the code Opus 4.8 is able to generate appears competent, but if you dig a bit, it contains way more timebombs than anything I've seen the team members develop.

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

#129

Post by this_user »

Atotalnoob wrote: post #11
MuffinFlavored wrote: post #5

I know a ton of people absolutely hate this level of "LLM code + LLM PR description + LLM PR review" but my boss would have an orgasm if I was able to use AI half as well in our org... :/

Just stop caring about quality. It makes it 10x easier to produce slop with AI if you never bother to check

Software Engineering may have very well entered its own Eternal September.

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

#130

Post by anematode »

mirekrusin wrote: post #113
tomjakubowski wrote: post #97

For what it's worth: this isn't a PR on mainline WebKit. The PR is on bun's own fork of WebKit (and JSC), which already has a bunch of their own changes.

Did they rewrote WebKit in Rust or not yet?

I'd actually love to see a relatively high-performance (i.e., including a decent JIT) runtime for a dynamic language that's written in Rust. There's a lot of implementations like Rust Python, the Boa JS engine, etc. that are purely interpreted – and fun! – but I haven't seen a proper, high-performance VM yet.

I considered writing such a JVM in Rust, following writing one in C (https://github.com/anematode/b-jvm) that could JIT WebAssembly code and run in the browser, but decided it would be too time-consuming.

Obviously such a VM would involve a lot of unsafe, but I'm wondering if you could establish some proper, compile-time-checked invariants that make things a lot safer, without the complicated sandboxing that modern JS runtimes use to make it harder for JIT bugs to escalate into full blown RCE.

Post reply on HN