Live data from Hacker News

Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

twitter.com

741–750 of 754 posts

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#741
post #75

Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languag…

>Rust is perfect for writing all of code using LLM. Rust is a terrible language for using LLMs to write code if Rust's low latency isn't needed, because of its extreme compile times. LLMs code faster than humans so a far bigger fraction of the time is spent waiting for the compiler, and a reasonably sized project will take literally 10x longer to compile in Rust than in e.g. Zig or Go.

In my experience with Claude Code, it writes most of the code, including tests, without invoking the compiler until the very end (almost like a spelling checker). Rarely are there any compilation problems, and when there are, it’s often a token issue like a missing brace. I hypothesize this is possible because of the robust invariants of the language itself, and its strong types, such that the LLM can encode deeper meaning in fewer tokens.

Also remember, `cargo check` is quite fast, and wholly sufficient for confirming correctness.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#742
post #105

Earlier quoted context omitted.

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

If this experiment ends up resulting in a real migration path, I think that would be completely awesome. Maybe it means we have a chance to revive older projects such as ngspice [0], but with modern affordances and better safety properties. From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair? [0] https://ngspice.sourceforge.io/

I've found Rust to be pretty enjoyable to work with in terms of Agent assisted development. Easier still if you have something you're trying to port or recreate in Rust for various reasons. There are definitely some rougher edges around a few things as you get more general purpose in terms of app targets. Some of the DB engines can use some work or may be missing interfaces you use in other supported languages/platforms... There's a somewhat limited set of UI options, and no clear winner.

Lifetimes can get pretty hard in very complex code bases... even if other aspects of burrow checking may be more common, this is where I've had and seen the biggest gaps in understanding in practice. That said, you can usually do inefficient things to work around these issues with the opportunity to come back later. Often inefficient Rust with lots of clone operations is still faster, smaller, lighter than the same services in Java or C# as an example.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#743
post #75

Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languag…

> Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow. I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases. On the other hand, Rust is a complex…

Sure, but if the initial architecture is bad for most mainstream languages, trying to do a huge cascading refactor is equally hard, but at the end the result is a lot less likely to work, so you don't so it at all and end up in the same spaghetti mess.

The lesson here is that right now LLMs are a lot better at "fill in the implementation for this API I defined" than "design everything from scratch" if you care at all about whether it becomes a mess of spaghetti. Maybe someday they'll be better at it, but at least today, you have to choose between going full vibes and not caring about the code, or you need to be involved in the design, and either way it's not clear that Rust is a significantly worse choice based on anything other than your own experience.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#744
post #262
post #75

Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languag…

I’ve struggled to get Opus to not write the weirdest possible Rust, ignoring all idioms and so on. Any tips?

I found that turning on every possible clippy lint and telling it that it has to run clippy as well as tests before it can claim it's finished helped a decent amount. Of course, if you have a decent-sized codebase of Rust you're happy with, it helps immensely, since it will tend to listen to follow instructions to follow existing patterns.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#745

Earlier quoted context omitted.

A SMT solver may work better.

Will that work if my codebase is filled with nils it shouldn't be filled with, and HashMaps instead of structs with a loosely defined schema, and tuples masquerading as arrays?

[dead]

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#746
post #259

Earlier quoted context omitted.

Great case where rust works well too. I won't cite every famous libs that got rewritten in rust but it wasn't all with LLM.

I fail to think of a successful Rust rewrite, so far what I've seen is just programmers who aren't sufficiently experienced, who decide to pick Rust and rewrite something in it, and then (this is the bad part) claim it's better for that reason only. It never is. It's always worse, because rewrites fundamentally end up with a worse product first.

ruff is a rust rewrite of flake8. Got bought by OpenAI after a meteoric rise in the python ecosystem.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#747
post #6

Earlier quoted context omitted.

But I am talking about Zig and others who have the same stance. Zig has a very strict No LLM / AI contribution policy and it likely got in the way of the Bun maintainers at Anthropic. From [0] >> No LLMs for issues. >> No LLMs for patches / pull requests. >> No LLMs for comments on the bug tracker, including translation. [0] https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy

They don't hate it. There's no antagonism that I know of there. I believe they want it to be fully human-authored and want low-hanging fruit items to be good onboarding for developers, not targeted by AI contributions. Simon Willison wrote a good blog post on it: https://simonwillison.net/2026/Apr/30/zig-anti-ai/ The Bun pull request was refused for additional reasons: 'AI is entirely beside the point here...': https…

how do you square that with the "no LLM translators" rule? i agree i dont think they hate LLMs but that one seems unreasonable and odd, and makes me wonder if its ideological after all

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#749
post #212

Earlier quoted context omitted.

you know this whole exercise is both a marketing exercise and a way to make noise. would the world come to a standstill tomorrow if every Bun instance out there ran on Node.js ? they know their A.I can't sell without the noise that it's now on the edge of the frontier. this is hype. zig adopting a strict 'no LLM' policy affects the LLM vendors.

If you think Claude needs manufactured hype at this point to sell it you're delusional.

it does tho is the thing, like if someone is fine with using a non-SOTA model then no, but those people are probably happy with deepseek or something cheap like that, if you feel you need to be on the absolutely frontier of commercially available that's OpenAI right now, they need to convince those people they are not too far behind if they are still only using Opus or enroll them onto Mythos.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#750

From 4 days ago: https://news.ycombinator.com/item?id=48019226 > I work on Bun and this is my branch > > This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. > > I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get i…

He works at claude, he has unlimited tokens. He can do anything, he is using mythos.

what one has to do when corporate does not not them use GPT-5.5
Post reply on HN