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

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

twitter.com

Post reply on HN
Print view View original

221–230 of 754 posts

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

#221

Post by bicepjai »

mohsen1 wrote: 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 amazing, but the way I want to build Rust software breaks down on large projects with LLMs. Maintaining clean boundaries or even just establishing them stops being a flow state and turns into painful reviews that push me into procrastination mode.

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

#223

Post by __s »

jadbox wrote: post #89
akagusu wrote: post #30

What does this mean for Zig? Few big popular projects use Zig, if they start to move away from it, what Zig's future will look like?

Jarred has already said on Twitter that this was only an experiment for comparisons and very, very unlikely that they'd switch to Rust.

https://news.ycombinator.com/item?id=48077663

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

#225

Post by gobdovan »

carllerche wrote: post #191
cornholio wrote: post #172

Earlier quoted context omitted.

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

> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.

It can happen like this:

- write sleek operator-overloading-based code for simple mathematical operations on your custom pet algebra

- decide that you want to turn it into an autograd library [0]

- realise that you now need either `RefCell` for interior mutability, or arenas to save the computation graph and local gradients

- realise that `RefCell` puts borrow checks on the runtime path and can panic if you get aliasing wrong

- realise that plain arenas cannot use your sleek operator-overloaded expressions, since `a + b` has no access to the arena, so you need to rewrite them as `tape.sum(node_a, node_b)`

- cry

This was my introduction to why you kinda need to know what you will end up building with Rust, or suffer the cascade refactors. In Python, for example, this issue mostly wouldn't happen, since objects are already reference-like, so the tape/graph can stay implicit and you just chug along.

I still prefer Rust, just that these refactor cascades will happen. But they are mechanically doable, because you just need to 'break' one type, and let an LLM correct the fallout errors surfaced by the compiler till you reach a consistent new ownership model, and I suppose this is common enough that LLM saw it being done hundreds of times, haha.

[0] https://github.com/karpathy/micrograd

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

#226

Post by 59nadir »

rvz wrote: post #32
Defletter wrote: post #24

Earlier quoted context omitted.

Exactly

This is exactly how Anthropic will market this rewrite towards companies thinking about doing more layoffs. 1 person did a rust rewrite that took 6 days that would have taken hundreds of engineers more than a year to do.

It probably wouldn't take a single person who knew what they were doing more than a year to re-implement Bun in basically anything, by hand and from scratch, i.e. not even looking at source. Writing the code for something you already understand and have built before is incredibly fast.

I'm sure they'll market what you said, but it's so ridiculous that I would hope people would see through this stuff.

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

#227

Post by lanthissa »

mohsen1 wrote: 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…

shouldn't typed code that uses functional style be kinda the perfect end game for llms? You can parallelize generation at any granularity, easily ring fence changes, reproduce everything, types give clues to the llm.

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

#229

Post by iwontberude »

afavour wrote: post #52

Presumably the biggest loser in all this is Zig, I only know of the language because of Bun. But the timescale still gives me pause… just because AI lets us convert a codebase in 6 days doesn’t mean it’s wise. There are surely a lot of downstream implications! It’s always felt a little like Bun is making up a plan as it goes along (and maybe that’s unfair), this seems to underline the point.

But the author said "the code truly works, passing the test suite on Linux and soon other platforms" which just sounds really wise.
Post reply on HN