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

371–380 of 754 posts

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

#371

Post by vb-8448 »

spicyusername wrote: post #11

What a time to be alive. So much of the fundamental dynamics of the industry and the job have changed in so little time. Basically over night. Some days I am so excited at how much I can do now. You can build anything you want, in basically no time! 100% of my software dreams can be a reality. Some days I am terrified at what's going to happen to the job market. Suddenly you can get so much with so little. The world…

Let's take a SW business like a ticketing system.

Do you think 100 enterprises with 1 bln of tokens are going to make a better product than specialized vendor with 100bln of tokens?

For sure SW vendors and SAAS like "logo creator" are already dead, but unless the next generation of LLMs aren't going to have an embedded ticketing system the ticketing system vendor will be fine(maybe less headcount, but not sure).

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

#372

Post by skeledrew »

bsder wrote: post #298
gobdovan wrote: post #256

Earlier quoted context omitted.

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/

[flagged]

I see "sourceforge" and immediately I think "this project is way behind time and is going to pose a lot of issues to new users, if it's still active".

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

#373

Post by rst »

yrds96 wrote: post #311
tmaly wrote: post #36

Just a cautionary case of porting to Rust using AI https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

Also passing tests doesn't mean something works. Claude code C compiler passed 100% of gcc tests and couldn't even run a hello world...

It couldn't run "hello, world" on systems where the include files were not located in the directory that it expected -- producing instead diagnostics saying, quite clearly, that the header files were not found. On systems where they were, it built versions of postgresql, redis, and several other things which passed their test suites completely.

If you've heard this problem described as a fundamental limitation of the compiler, and not the kind of packaging glitch that's routine to find in pre-alpha software of all descriptions, whoever described it to you that way is not serving their readers well.

I'm not saying CCC was production-ready, or close -- the total lack of an optimizer would be a killer in any real use, and I assume that there were problems with the diagnostics at least as bad as problems with performance and the include files, for similar reasons -- the LLMs hadn't been asked to optimize for that stuff yet, just test suite correctness. But it did achieve that, and the amount of cope I've seen on social media claiming otherwise is more than a bit disturbing.

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

#374

Post by cdelsolar »

oytis wrote: post #267
zaptheimpaler wrote: post #236

Earlier quoted context omitted.

This is such a bad faith argument. How long would it take a dev or a team of devs to do this with the same architecture and test suite? A hell of a lot longer than 6 days..

But what is the purpose? When you rewrite a project in another language, it's for engineers to be able to maintain and further develop the project better on some metrics due to advantages of the language. It doesn't hold when LLM does the rewrite, since there is no one who understands the code after that. It's a good demonstration of capabilities, sure, but the result itself makes no sense. We'll have to figure out w…

why do you think no one understands the code after the LLM rewrites it?

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

#375

Post by brazukadev »

enricozb wrote: post #42
mi_lk wrote: post #37

Earlier quoted context omitted.

> Bun has had an extremely high amount of crashes/memory bugs Any stats/source? Not that I think it's false > and the ugly parts look uglier (unsafe) which encourages refactoring. Looks like Bun owes that to itself to some extent, not solely because of the language

I believe the author is the creator of Bun.

Is he working for Anthropic now?

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

#376

Post by jwpapi »

voidhorse wrote: post #323

So let me get this straight: Developers use LLMs to migrate a million line codebase to a language that they have much less experience with in such a short amount of time that they likely do not have a good mental model of the migrates code. At least the tests pass. Only one person drove the migration, so the number of people that understand the new code is ~0.5 under the assumption there's no way the sole dev could b…

Thank you put my gut feeling that I had in my top comment here in words. I didn’t have the full explanation ready, why this threw me off.

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

#377

Post by gobdovan »

skeledrew wrote: post #372
bsder wrote: post #298

Earlier quoted context omitted.

[flagged]

I see "sourceforge" and immediately I think "this project is way behind time and is going to pose a lot of issues to new users, if it's still active".

I could have linked Github repo which has been abandoned for 11 years and ranks higher on Google than the sourceforge page, but that would have maybe been disingenuous. (https://github.com/ngspice/ngspice)

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

#378

Post by eqvinox »

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

That's not a revive though, revive (at least to me) implies it's dead.

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

#379

Post by HumanOstrich »

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.

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

#380

Post by josephg »

dnautics wrote: post #175
josephg wrote: post #133

Earlier quoted context omitted.

Nope! Zig is like C in this regard. There’s no borrow checker. Managing memory is your responsibility. It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.

It's not.. but im pretty sure it could be. could probably even take this (WIP) idea and bolt on a formal verifier pretty easily. https://github.com/ityonemo/clr

It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust knows when it can Drop). And rust can put noalias everywhere in emitted code. And you'd probably have worse error messages than the rust compiler emits.

Its an interesting idea. But if you want static memory safety in a low level systems language, its probably much easier to just use rust.

Post reply on HN