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

431–440 of 560 posts

Re: Rewriting Bun in Rust

#431

Post by pron »

Sounds to me like his choice of Zig was made in haste, as was his choice of Rust. If you find yourself changing a project's primary language more than once a decade (more like 15 years, but let's say a decade), the problem isn't the language but your technical decision process, and that's what you should look into first.

Some of the world's more important software - from browsers to the JVM - mix high-level languages with a GC and low-level languages, and it works not because of a style guide (even though one may exist). As someone working on the HotSpot JVM, I can say that it's done with a lot of thinking about constructing the right primitives that make this work well. Zig doesn't lack the features to construct the mechanisms required for getting good results in that domain, and Rust doesn't have features that could save you the thinking about such mechanisms.

Re: Rewriting Bun in Rust

#432

Post by erichocean »

smasher164 wrote: post #198

It's still shocking to me that the approach taken wasn't to have Claude write a tool that translates Zig to Rust. I imagine it would've been cheaper, deterministic, and each iteration would produce a better tool.

That's the approach I've taken with a bunch of legacy OpenCL code I've mechnically translated to Metal, worked great.

Re: Rewriting Bun in Rust

#433

Post by MrCheeze »

ameliaquining wrote: post #94
Buttons840 wrote: post #78

I've always felt [0] the people who created Bun had, as their first and foremost goal, a desire to use Zig--and that's great, I like Zig, I like when people build things their own way. However, I've been skeptical of using Bun, because I want a project whose first and foremost goal is to build good tools that achieve the objectives of the project. It reminds me of asking game developers: Do you want to build a game ,…

So does that mean the rewrite made you less skeptical?

I mean, surely the main motivation for "use an LLM to rewrite a huge project in a new language" was excitement about the shiny new tech that made it possible.

Re: Rewriting Bun in Rust

#434

Post by jjice »

dwdz wrote: post #377

"The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article." -- Andrew Kelley https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

Without accusing anyone of anything, I do think that this coming from the head of Zig, who gets a lot of negative publicity from the Bun rewrite (unjustifiably, it's a wonderful language) makes it harder for me to take this without wondering if there's some animosity that's really the main complaint.

> Two, I actually don't have any personal criticisms of Jarred

The author says two things that really popped out to me that you could say are "professional" and not "personal" criticisms, but I think they're still rude and contrast this statement.

> Jarred was already writing slop well before he had access to LLMs

> The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience

Now, both of these may be true. I don't have any evidence though, so I don't know how to take it.

All this to say, I'll take both of these posts without a ton of salt when it comes to the non-technical parts.

Re: Rewriting Bun in Rust

#435

Post by jjice »

talloaktrees wrote: post #82
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.

I like using Odin with LLMs for this. it's a simple statically typed language with no GC and very fast compile

But then you have to deal with manual memory management. Not a bad thing, but it's the big win you get from GC languages and Rust.

Re: Rewriting Bun in Rust

#438

Post by Ygg2 »

afry1 wrote: post #429
padjo wrote: post #421

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…

Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world. PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future. AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that. As…

> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.

Not really. LLMs are a tool, and they do possess some interesting properties, but they are, in essence, a very surprising auto-complete.

No, what sucks is the AI companies marketing them as if they are The Holy Grail. And people are assuming that somehow LLM -> AGI -> ASI, even though there isn't really a causal link to be had, and acting like it's The Singularity.

I don't blame autocomplete for fucking up RAM, labor and god knows what else. I blame the idiots (at OpenAI and Anthropic) buying all RAM stocks and pretending this shit is any way good for anyone.

Re: Rewriting Bun in Rust

#439

Post by ubercore »

sneak wrote: post #327
Gigachad wrote: post #179

Earlier quoted context omitted.

I've observed that dumber models are able to vibecode in safe languages a lot easier since the compiler errors can self correct the models hallucinations, while they end up marking a task as complete in dynamic languages despite it not actually working. If I'm vibe coding something I'm always just going to do it in Rust.

Agree 100%. Almost everything I have written with AI is in Go, and strong typing is really really nice (as is go vet and golangci-lint to keep the generated code in line). I imagine writing plain js or python with it would be much much riskier.

Well annotated code is fine in Python too.

Re: Rewriting Bun in Rust

#440

Post by zdragnar »

stymaar wrote: post #323
MobiusHorizons wrote: post #296

Earlier quoted context omitted.

Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.

> Why do you think it is not slow? The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means. > I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable f…

Most people use esbuild or swc or oxc instead of the typescript compiler directly specifically because of how slow tsc is.

In fact tsc was slow enough that it was rewritten into a different language for version 7, with the performance of the compiled output as the primary motivation.

Post reply on HN