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

31–40 of 560 posts

Re: Rewriting Bun in Rust

#31

Post by giancarlostoro »

YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

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

Re: Rewriting Bun in Rust

#32

Post by fernando-ram »

gpm wrote: post #24
fernando-ram wrote: post #10

[flagged]

1. There's no comparison - it's just showing a snapshot in time (apparently post port). You literally can't!? 2. Of your 8 comments on this site, 7 are spamming links to this site. I at least don't think that's ok.

Yeah, thats on me I got a little lazy. Im not trying to spam, It my project because I think its cool to see projects this way and I think it can make software more digestable and less nebulous a concept

Re: Rewriting Bun in Rust

#33

Post by sroussey »

giancarlostoro wrote: post #31
YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

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

Agree. But just because it feels the same doesn’t mean it compiles the same.

Re: Rewriting Bun in Rust

#34

Post by duhhhhh1212 »

gpm wrote: post #20
duhhhhh1212 wrote: post #17

Where is the cost breakdown? I feel like this would be the easiest number to determine and write in this post. It's hard to believe that there have been no problems/downsides since the port.

> Where is the cost breakdown? From the article > Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing > It's hard to believe that there have been no problems/downsides since the port. A significant portion of the article was dedicated to the 19 regressions they've found. Starting here: https://bun.com/blog/bun-in-r…

Thanks!! Those are solid numbers but confusing. He reported input, output, and cached input token reads but not cache writes/cached creation input tokens? Maybe cache writes aren't a thing internally?

Re: Rewriting Bun in Rust

#35

Post by benced »

YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

Not a compiler expert - shouldn't language verbosity and binary size be, at best, very loosely related?

Re: Rewriting Bun in Rust

#36

Post by ianm218 »

Inspired by this project I ported most of Valkey to Rust here valdr.dev .

The coolest outcome was being able to run a redis comparible store on an a cloudflare durable object so you do I.e. rate limiting for free with little infra.

Re: Rewriting Bun in Rust

#37

Post by Georgelemental »

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…

Pre-release code had bugs that were fixed before the release? Why is that a problem? That's the point of having a testing and release process

Re: Rewriting Bun in Rust

#38

Post by giancarlostoro »

So I kept hearing that the author did this purely because Anthropic wanted a PR story, but reading this entire very well written post, with meticulous detail, what say you now? I never thought it made any sense for him to do this just because Anthropic asked him to. Sometimes you find yourself fighting the stack you're currently using, and another stack (or programming language) looks like it would alleviate a lot. LLM was just another tool in his toolbelt. I had already ported projects that were old and abandoned before using Claude Code, so I knew it was possible.

Re: Rewriting Bun in Rust

#39

Post by gpm »

lifthrasiir wrote: post #30
theLiminator wrote: post #28

That's the power of a strong test suite. LLMs excel when you have verifiable rewards. I imagine we'll get a lot more rewritten in rust projects in the future. Rust is also an ideal target for such rewrites as it offers a lot of verification (via its type system) and is low overhead with zero-gc. There's less and less reason to use GC'd languages in the agentic coding era. I think Rust is a locally optimal target for…

> 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 odd person who does that) so we don't have to worry about things like whether a variable is stack or heap allocated. Which is in the direction of a GCed language but retains the mutable-xor-aliasable semantics.

Between rust and current GCed languages though... I guess I agree with "maybe" in both directions.

Re: Rewriting Bun in Rust

#40

Post by benced »

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.

Post reply on HN