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

471–480 of 754 posts

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

#471

Post by ycui7 »

aragilar wrote: post #453
nextaccountic wrote: post #430

Earlier quoted context omitted.

> and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). Solving sets of differential equations is something that's parallelizable though See for example how there's physics engines running on GPU. That's mechanics and not electric circuits, however it's differential equations all the same.

Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable). Mechanics is generally linear, and for game physics engines…

The type of people who need spice is dead serious about accuracy. 1ppm error sometimes is not tolerable. So, an optimization in a game engine is definitely not suitable for engineering simulation.

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

#472

Post by ted_dunning »

aragilar wrote: post #453
nextaccountic wrote: post #430

Earlier quoted context omitted.

> and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). Solving sets of differential equations is something that's parallelizable though See for example how there's physics engines running on GPU. That's mechanics and not electric circuits, however it's differential equations all the same.

Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable). Mechanics is generally linear, and for game physics engines…

To be specific, a linear solver can be (as in I have done) written in a week.

A serious non-linear solver that handles legacy Spice models is another beast entirely. And if you want to integrate modern advances in algebraic-differential systems you take that to a higher level.

These are not partial differential equations such as you find in Navier-Stokes. These are sparse non-linear differential equations that do not parallelize nearly as simply.

Another example of related problems that parallelize poorly even though they are linear are the FDTD formulations for Maxwell's equations. These are relatively simple systems, but the bottleneck is almost always the memory bandwidth because it is so hard to parallelize.

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

#473

Post by toshinoriyagi »

NewsaHackO wrote: post #395
toshinoriyagi wrote: post #360

Earlier quoted context omitted.

Well they haven't lost anything yet. Somebody is vibe coding a rewrite in another language and we don't know much else. The author said he will write a blog post about it soon. So far all we know is it is passing most of the test suite. But Bun has open issues and bugs. The test suite doesn't tell us whether it has introduced many new bugs, solved existing ones the test suite doesn't catch, or anything else. Not to m…

>Having a project consider a rewrite isn't so big a deal. I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite. >I don't think the Zig team is concerned at all. I wonder if that's the mentality that got them in this situation in the first place.

>I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite.

You're right, a rewrite is in existence, and whether it is good enough to be used or expand upon is what is being considered. I don't think that changes the fact that languages don't live or die by whether or not 1 large project using them continues using them. Especially a language like Zig which has taken plenty time making breaking changes. They know this is par for the course.

>I wonder if that's the mentality that got them in this situation in the first place.

I highly doubt it. To my knowledge, the only "why" Jarred has given is frustration with memory issues. Speculated reasons I see are: 1. Anthropic wants a rewrite to a language with a more favorable AI contribution policy, to avoid bad press by acquiring a framework written in a language that is skeptical of AI code quality. 2. Rust is more stable and a better target for AI-assisted programming or entire vibe coding. 3. Bun is upset Zig does not want to merge their fork into main.

Focusing on the issue Jarred gave as why he started the rewrite, I don't see how Zig got themselves into the situation at all. Zig was always upfront that it aimed to be a modern C: simple language, powerful modern features, and excellent compatibility with all things C. While it certainly has much better behavior concerning memory safety and undefined behavior, it has never aimed for Rust or GC level memory safety.

It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. I think Jarred is in this situation because he wants to be, simply. He works for Anthropic, probably has no limit on how many tokens he spends, and may have access to their most powerful internal models like Mythos. I would guess he pointed agents at this problem and let them go, because why not? He has likely has no opportunity cost.

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

#474

Post by osti »

Gigachad wrote: post #461
Aurornis wrote: post #156

Earlier quoted context omitted.

Translating a project that includes a good test suite from one language to another is known to be a great case where LLMs work well. When you’re starting with a complete codebase to use as an example and a test suite to check everything it’s much easier to iterate toward the desired goal. The LLM can already see what the goals are and how they’ve been implemented once already, which is a much easier problem than star…

The goal posts are always moving. This would have been an unthinkable task a couple years ago.

Even last year at this time people wouldn't believe it.

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

#475

Post by danipark »

anilgulecha wrote: post #9

I think the industry is moving to English as the programming language, and specifications-context-tdd as the framework for building software. Many find it distasteful, and many finding liberating. I think it's broadly correlates with how they feel about expressing themselves in english vs say C++. As a side question, is there anyone who's using LLMs primarily in non-english mode to program? I suspect there's quite a…

I’m Korean, and I’ve used GitHub Copilot, Claude Code, and Codex. At first, I prompted them in English, but over time I came to the conclusion that using Korean works better for me. It may consume more tokens, but reducing the time spent understanding and correcting the plan is more valuable. That said, when the context gets close to its limit, the responses sometimes include Korean words that do not actually exist.

As an aside, I don’t think the benefits LLMs bring to non-English users are widely understood. I studied linguistics and Russian, and I’m capable of professional interpretation in English and Russian. Even so, I can read technical documents, understand them, and communicate about them much faster and with far less effort in my native language, Korean. These days, I read most English documentation and HN posts through Chrome’s automatic translation. Sometimes the translation is ambiguous, but in those cases I can immediately refer back to the original English. This has been a major help to me and to other Korean developers I work with.

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

#476

Post by giancarlostoro »

pier25 wrote: post #446
jwpapi wrote: post #314

Completely unbased, but I don’t want to have to do anything with bun anymore. It’s just a gut feeling, but I don’t trust them and support them. They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling) And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enfo…

> It’s purely politics-based not technical Jarred mentioned having to work on fixing memory leaks as the main motivation to try this. https://xcancel.com/jarredsumner/status/2053058171338682875#... I was never fully comfortable with Zig given it's much less mature than Rust. Maybe this will be for the better.

I mentioned a similar sentiment 4 days ago in the original discussion about this project, and HN for some reason did not like that I noted Rust is used in production longer and way more than Zig is, including Firefox, CloudFlare's own reverse proxy, Discord, and many other massive effort projects that affect millions if not billions of people.

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

#477

Post by geysersam »

erkat wrote: post #249
christopherwxyz wrote: post #152

Earlier quoted context omitted.

It’s disrespectful to immediately jump to adversarial conclusions from a simple desire to refactor and poor netiquette.

If experienced (in open source and corporate politics) developers would bet on Polymarket if the rewrite is going to be ultimately merged, which side would you bet on? What would the emerging odds be? My guess is 19/20 in favor of ditching Zig. I have followed many initial denials on a wide range of topics, not only rewrites, over the years. Like clockwork, most of them were lies.

I don't think there's much chance it gets merged.

Even if it passed the full test suite there are a ton of software qualities that are not captured by tests and I think it's unlikely the AI made the right trade-off in every such case.

* We haven't seen the benchmarks yet.

* It hasn't seen wide usage. Zig Bun has had tons of bugs ironed out, Rust Bun has a different set of bugs to iron out.

* The developers know the zig codebase well, they don't know the rust code base.

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

#478

Post by geysersam »

theptip wrote: post #247
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…

> Rust is a complex language prone to refactoring avalanches This may be so, but LLMs are great at slogging through such tedious repercussions. I would say if the language prevents sloppy intermediate states, that actually makes it more amenable to AI; if you just half-ass a refactor into a conceptually inconsistent state, it’s possible for bad tests to fail to catch it in Python, say. But if many such incomplete sta…

This is true in my experience as well. I'd even say it's the most common failure mode of current AI! It "fixes" some problem locally and declares victory, but it doesn't fully address the consequences of the change everywhere, and then the codebase is inconsistent.

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

#479

Post by irishcoffee »

johncolanduoni wrote: post #319
yrjrjjrjjtjjr wrote: post #198

Earlier quoted context omitted.

The right to be suspicious of the motives of powerful people is infinitely more important than protecting their feelings from being hurt by suspicion.

Powerful people figured out how to make suspicion work for them long ago. You have every right to be unconditionally suspicious, but it’s not a good way of accomplishing any change. Also their feelings are not hurt by what you or I think, they don’t care.

> Powerful people figured out how to make suspicion work for them long ago. You have every right to be unconditionally suspicious, but it’s not a good way of accomplishing any change.

How does one accomplish change? Even being a martyr doesn't get traction. As far as I can tell, you need to already be powerful. Nobody lets you into that group if you're not aligned with said group.

Protests (at least in their current form) don't work. Trying to assassinate someone doesn't move the needle (also not the play, I don't support murder), vocal grassroots leaders are no longer relevant at all, if they ever were.

How does one accomplish any change?

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

#480

Post by josephg »

dnautics wrote: post #467
josephg wrote: post #451

Earlier quoted context omitted.

> and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm co…

> Can you give some examples? I've never ran into problems due to this. If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D

> If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted.

Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essential tool for optimisation.

The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.

Post reply on HN