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

391–400 of 754 posts

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

#391

Post by andriy_koval »

NewsaHackO wrote: post #161
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?

I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Worse, the project felt like Zig wasn't meeting their needs, to the point they abandoned Zig and rewrote their entire project in a different language. Really bad signal for anyone thinking of using Zig for a big project. It is still in beta, but has there been any situation like this, where a upcoming program…

Is it lost already? Did antropic already say new LLM generated thing is way to go for the future?

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

#392

Post by bsder »

etimberg wrote: post #370
eqvinox wrote: post #309

Earlier quoted context omitted.

+1, a project presenting at FOSDEM certainly does not need a "revive".

The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable

> The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable

That code is also hyper-optimized for performance. I sincerely doubt you are going to match the performance easily with any random rewrite.

Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you might stand a chance of producing something that would outperform it. Or, perhaps, if you had particular knowledge of modern high-performance numerical libraries that you could apply to the problem, then you might be able to beat it.

However, circuit simulation is remarkably difficult to get right (stiff systems with multiple time constants are not uncommon) and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations).

If, however, the legacy of ngspice bugs you that much, go look at Xyce and see if that is more to your taste.

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

#393

Post by perching_aix »

aabhay wrote: post #382
perching_aix wrote: post #116

> and crashes and stability issues inb4 .unwrap() / slice / etc hell + livelocks & deadlocks + resource leaks & toctou bugs + larger exposure to supply chain attacks Still, ~1M LOC ported in a work week (400 LOC/min, wtf?) and almost all of it working is pretty wild. I hope the guy managed to maintain normal function, cause I found that getting into the flow but with AI is even more self-consuming and intoxicating th…

At 100 agents in parallel that’s 4loc/min, and 100 agents is a lower bound on what they had access to.

It's not so much the agents' througput I'd be worried about, more meant to imply that at such speed, large parts of this are going to be pretty much just guaranteed unsupervised / unchecked completely. Like literal "LGTM + god bless + fuck it we ball" tier.

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

#394

Post by rstuart4133 »

apitman wrote: post #283
carllerche wrote: post #191

Earlier quoted context omitted.

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

This post has some good examples of this sort of problem: https://loglog.games/blog/leaving-rust-gamedev/

That link reads like an autobiography about his love affair with Rust and subsequent breaking up after pushing the relationship a step too far: into gaming. He has been using Rust much, much longer than me, but I rekcon I already hit most of the pain points he mentions. (And I notice he left some things out, like async.)

I've come away feeling that most it looks fixable - but it won't be fixed in Rust. Some of the language choices (like favouring monomorphization to the point of making dll's near impossible) are near impossible to undo now, and in other cases where it might conceivably be fixed (like async) it won't be because the community is too invested with their current solution.

So we are stuck with the Rust we have; warts and all. That blog post convinced me those warts mean the language should be avoided for game development. Similarly sqlite developers convinced me the current state of Rust tooling meant it wasn't a good fit for their style of high reliability coding, so they are sticking with C. Which is a downright perverse outcome.

But for most of us C programmers who aren't willing to put in the huge effort Sqlite does to get the reliability up, Rust is the only game in town right now. It's the first and currently only language to implement a usable formal proof checker that eliminates most of the serious footguns in C and C++. But I am now hoping it becomes a victim of the old engineering adage: plan to throw the first one away, because you will anyway.

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

#395

Post by NewsaHackO »

toshinoriyagi wrote: post #360
NewsaHackO wrote: post #161

Earlier quoted context omitted.

I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Worse, the project felt like Zig wasn't meeting their needs, to the point they abandoned Zig and rewrote their entire project in a different language. Really bad signal for anyone thinking of using Zig for a big project. It is still in beta, but has there been any situation like this, where a upcoming program…

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.

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

#396

Post by stingraycharles »

woah wrote: post #390
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…

Who's the whiny baby? The developer writing some code in their own repo, or the guy complaining about it on Hacker News?

Yeah I also noticed this irony. In addition to accusing the rewrite to being political and not technical, while their whole comment is being political not technical.

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

#397

Post by twoodfin »

carefulfungi wrote: post #143
twoodfin wrote: post #29

Earlier quoted context omitted.

You could have said the same thing about steam power or electricity. And it’s not just an analogy: The magic of these things is in being universal information engines. You spend capital to build them, using well-understood, scalable techniques, plug them into electricity, and out comes value. My point is, there’s no chance of a “haves and have nots” emerging, any more than electricity turned out that way in the moder…

Electricity might be a good analogy - but for the other side of this argument. In the US, (nearly) full electrification wasn't achieved until the late 1940's/early 1950's - a process of nearly a century. (A moment of personal trivia, my great grandfather worked on crews electrifying rural areas of the midwest.)

We already have SOTA local inference devices in everyone’s pocket, which also provide high bandwidth access to SOTA data center inference at what is rapidly becoming commodity pricing.

What comparable gap is there to bridge?

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

#398

Post by reactordev »

SuperV1234 wrote: post #346
sysguest wrote: post #118

Earlier quoted context omitted.

> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. haven't used zig...(only used rust) but zig doesn't solve those problems?

Zig doesn't even have RAII...

which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.

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

#399

Post by jwpapi »

stingraycharles wrote: post #396
woah wrote: post #390

Earlier quoted context omitted.

Who's the whiny baby? The developer writing some code in their own repo, or the guy complaining about it on Hacker News?

Yeah I also noticed this irony. In addition to accusing the rewrite to being political and not technical, while their whole comment is being political not technical.

I meant my comment not the rewrite

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

#400

Post by stouset »

HumanOstrich wrote: post #379
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…

Yep, the Anthropic acquisition, this petulant Rust rewrite, and bun's increasingly buggy releases (slop) have caused me to migrate my projects (personal and work) to nodejs+pnpm. The risks of using bun are no longer just those concerns around a newer tech and "drop-in" replacement for nodejs. Now you have to marry Anthropic, Rust, and a founder with conflicting priorities.

Having read the comments from the actual engineer doing this rewrite, the only petulance I have seen is from those reacting so strongly to it.
Post reply on HN