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

521–530 of 754 posts

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

#521

Post by smj-edison »

baranul wrote: post #502
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?

It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is. Zig is still under de…

You might want to check their Codeberg then, because they've moved all their development over there...

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

#522

Post by smj-edison »

zephen wrote: post #464
fooker wrote: post #422

Earlier quoted context omitted.

How is defer not magic sauce?

Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor. The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.

And more importantly, you can choose what destructor to call. This is perhaps what's most underrated about defer, because defer can select among many different destructors possible, at multiple different levels (group free with arenas, individual free, etc).

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

#523

Post by casey2 »

BigJono wrote: post #484
Validark wrote: post #429

Earlier quoted context omitted.

I'm team Zig in most cases but I genuinely think they are better off with Rust. They have had a lot of buffer overruns and segfaults as a result of undisciplined Zig code. I think Rust actually is a better technical choice for them.

[flagged]

I don't think that's going to save them. There are big problems and little problems. RAII+ownership/borrowing solves some memory and file handle issues. But the big problem and this happened before the rewrite, is that they have ceded the system level. Which locks the project into a local minima.

It's not a "your holding it wrong" problem it's a you fundamentally have no idea how your own program works past 1 or 2 level of indentation in most places. If the LLM says that something isn't possible you just have to take it at it's word.

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

#526

Post by vintermann »

bsder wrote: post #392
etimberg wrote: post #370

Earlier quoted context omitted.

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

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

But that's exactly the sort of exotic domain knowledge that AI models have that I don't.

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

#527

Post by russum »

libria wrote: post #304
jedberg wrote: post #208

Obviously there is a huge trend of "rewrite X in Rust". I understand why, Rust is a huge improvement in safety and speed. My question is, to people even older than me (and I'm certainly not young), does anyone remember this much enthusiasm about people rewriting C code into (C++/Java/Whatever was new and hot)? Because I don't, but maybe I missed it.

I recall C++ OOP being the new hotness when I started out and C was always contrasted as the old & busted example. Kind of the "Everything-as-an-object will simplify everything" phase. Windows MFC was the new way, then STL. Java WORA write once, run anywhere was definitely a thing when it came out. Java Applets came out of the woodwork and were the WASM of their day. Even Cisco ran Java for their router UI for a whil…

> every other article ended in " ... written in Go"

What happened to that: is Go no longer considered great / popular?

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

#528

Post by brabel »

josephg wrote: post #480
dnautics wrote: post #467

Earlier quoted context omitted.

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

In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.

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

#529

Post by baranul »

smj-edison wrote: post #521
baranul wrote: post #502

Earlier quoted context omitted.

It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is. Zig is still under de…

You might want to check their Codeberg then, because they've moved all their development over there...

Zig very much could of moved all of their GitHub issues over to Codeberg, to be resolved, but chose not to do so. Thus left thousands of issues unsolved and stranded.

This maneuver was arguably obfuscated by the anti-LLM stance and finger pointing at Microsoft, but nevertheless, many still have noticed. Zig, for a long time, had been falling behind and doing poorly on their open to close ratio for resolving issues. It should be embarrassing to leave so many issues open.

Even if not accepting new GitHub issues, they have demonstrated an inability to resolve existing issues, except at an extremely slow pace. Considering there are just about no new issues on their GitHub repo, it is understandable if there are those that find the pace to close and amount of issues unacceptable or questionable, in addition to the clearly bad open to close ratio.

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

#530

Post by lionkor »

Tiberium wrote: post #34

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

> Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.

Post reply on HN