Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

61–70 of 560 posts

Re: Rewriting Bun in Rust

#61

Post by wccrawford »

Atotalnoob wrote: post #42
benced wrote: post #40

Earlier quoted context omitted.

> We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. God forbid an engineer express uncertainty.

Uncertainty is one thing, but a high chance means it’s 51% or higher to me. Based on that, the bun rewrite messaging was fairly misleading.

That was their estimate at the time, based off the information they had. You can't ask more of someone than that.

Either they estimated poorly, or it ended up the lesser portion of their estimate after all. After all, unless the estimate is 100%, there's always a chance it'll fall into the other portion.

Re: Rewriting Bun in Rust

#62

Post by i_am_a_peasant »

afavour wrote: post #60
giancarlostoro wrote: post #31

Earlier quoted context omitted.

> Ironically, Zig is a programming language that's probably best written by LLMs, since they can tolerate actually tolerate the verbosity. Rust in my opinion feels the same.

I don’t feel the verbosity with Rust. Haven’t written it in a while but now in the LLM era I’m looking forward to saying “sort out the lifetime errors for me”.

I trust a lot more Rust code generated by an LLM than anything else ngl.

Re: Rewriting Bun in Rust

#63

Post by ivanjermakov »

SergeAx wrote: post #53

I still think that generating a Zig-Rust transpiler would be a better approach, given all the LLM quirks, including the ability to just /goal the model with binary-identical LLVM bytecode. However, an open-sourced tool like that would've greatly harmed the Zig ecosystem and community.

> would've greatly harmed the Zig ecosystem and community

People looking to abandon the ship first chance are unlikely to contribute much to the ecosystem and community.

Re: Rewriting Bun in Rust

#64

Post by lifthrasiir »

silver_silver wrote: post #56
lifthrasiir wrote: post #26

Earlier quoted context omitted.

The article explicitly mentions the maintainability as a foremost concern.

People say a lot of things, especially when they have a vested interest in a positive outcome. Bun has been fully vibe coded into another language. There’s no way in hell it’s maintainable. Go read any analysis of the Claude Code leak for proof.

Claude Code is entirely vibe-coded for a long time. Bun isn't. You go read and compare the actual Bun code; it reads reasonably well [1].

[1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...

Re: Rewriting Bun in Rust

#65

Post by saghm »

lifthrasiir wrote: post #22
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

The same concern applies to every GC language, so it's not necessarily bad for Zig. Bun can have been grown too large for Zig to be effective, while moderately sized projects may still greatly benefit from Zig.

I thought Zig was supposed to be a C replacement (as in, it doesn't actually provide full safety in the way that Rust or a GC language would)?

Re: Rewriting Bun in Rust

#66

Post by jen20 »

Atotalnoob wrote: post #42
benced wrote: post #40

Earlier quoted context omitted.

> We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. God forbid an engineer express uncertainty.

Uncertainty is one thing, but a high chance means it’s 51% or higher to me. Based on that, the bun rewrite messaging was fairly misleading.

To understand your error, consider that in the month leading up to the 2016 US presidential election, the widely-accepted probabilities were between 70% (Five-Thirty-Eight) and 90% (Reuters) in favour of Clinton.

Re: Rewriting Bun in Rust

#67

Post by hansvm »

benced wrote: post #40
dfabulich wrote: post #27

This blog post further undermines my trust in Jarred. He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues." But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719 Observers could see this coming from a mile aw…

> We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. God forbid an engineer express uncertainty.

Engineers are pretty jaded about plans expressed by authority, especially when there are obvious pressures opposing those plans. Yearly planning doesn't matter when a reorg will change the trajectory by Q3. Sprint planning doesn't matter when you know a fire will hit before then and you won't be given enough time budget to fix it well enough for that not to happen again next sprint. Project planning doesn't matter when the whole point is masturbatory spreadsheet production before you've actually taken a dive into the hairier details and figured out what's possible and what's necessary. That barely working demo strapped on top of a non-existent backend they swore would never become production? Congratulations, you have two weeks to build the next fake demo on top of it, but the base has to actually work now.

Maybe Jared just broadcasted uncertainty and was wrong, but given his position he's not being given the normal grace you might extend to an engineer you trust.

Re: Rewriting Bun in Rust

#68

Post by lifthrasiir »

saghm wrote: post #65
lifthrasiir wrote: post #22

Earlier quoted context omitted.

The same concern applies to every GC language, so it's not necessarily bad for Zig. Bun can have been grown too large for Zig to be effective, while moderately sized projects may still greatly benefit from Zig.

I thought Zig was supposed to be a C replacement (as in, it doesn't actually provide full safety in the way that Rust or a GC language would)?

Oh, yeah that might be confusing. I meant "you can say the same thing for GC language if that's true, which isn't necessarily true, so that must be false".

More precisely speaking: GC languages are said to delay memory problems far beyond the horizon, which is often unreachable throughout the project's history. Zig can be a similar case.

Re: Rewriting Bun in Rust

#70

Post by lifthrasiir »

gpm wrote: post #39
lifthrasiir wrote: post #30

Earlier quoted context omitted.

> There's less and less reason to use GC'd languages in the agentic coding era. Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.

Eh... rust's safety isn't free, but not having it and wasting time on "oh I forgot to change this call site" also isn't free. On the whole I'd say the safety assists in iteration time. What costs rust in iteration time in my opinion is the low level (by default) nature of it. There's a faster-to-iterate language that has yet to be created which is rust but we sacrifice performance (and memory fiddling ergonomics for…

The project in question needed lots of near-instant human judgements and the iteration loop had to be extremely tight. Maybe Rust should be reconsidered once it gets stabilized enough, but not right now.
Post reply on HN