Live data from Hacker News

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

twitter.com

301–310 of 754 posts

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

#301

Earlier quoted context omitted.

Software companies have been about automating human labor since the invention of computers. It's the whole damn point. Why do you think finance used to be (sometimes still is) the head of the IT dept? Because we automated accounting away. Then typists. Then secretaries. Then drafting. Etc etc.

> It's the whole damn point. Believe it or not, for some of us it’s not “the whole damn point”.

No one is taking away programming as a hobby from you :)

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

#302

3 years from now: Linux ported to Rust in 6 days. And on the seventh day Claude ended His work which He had done, and He rested on the seventh day from all His work which He had done

That's a fun point. I honestly don't think it will happen in 3 years, but I think it will surely doable in 10.

More interestingly: will we need to care about the code at all, at that point?

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

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

Same but for multi-threaded Postgres[0]. 96% pg regression tests pass after 1 month and 823K LOC. 8 Codex accounts at $200/mo is what i could use up with no Mythos I've also seen the benefits of Rust for this too. And making the bet that my pg experience will help me make good design choices around many of the things people have been having trouble with in pg for a long time[1]. Excited to see AI make it more possibl…

Very cool! If you have extra tokens laying around ask the agent try to break things and open GitHub issues. This is what I do for tsz and beyond conformance test I can see it finding very good bugs.

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

#304

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 while, which was painful.

More recently, HN went through a period about 10 years ago where every other article ended in " ... written in Go".

The mantra may not have rhymed with "rewrite X in Y" but the spirit was there.

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

#305

Earlier quoted context omitted.

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

> Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.

You know, I try to ask questions rather than making assertions in order to better my chances at provoking useful thought and conversation.

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

#306

Earlier quoted context omitted.

Software companies have been about automating human labor since the invention of computers. It's the whole damn point. Why do you think finance used to be (sometimes still is) the head of the IT dept? Because we automated accounting away. Then typists. Then secretaries. Then drafting. Etc etc.

> It's the whole damn point. Believe it or not, for some of us it’s not “the whole damn point”.

Whether or not you want to admit that is up to you. If you're selling automation or efficiency gains, you're removing human labor.

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

#307

Earlier quoted context omitted.

Software companies have been about automating human labor since the invention of computers. It's the whole damn point. Why do you think finance used to be (sometimes still is) the head of the IT dept? Because we automated accounting away. Then typists. Then secretaries. Then drafting. Etc etc.

[flagged]

"ok guys, that's enough progress since now it's my job at stake, we can stop."

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

#308
post #73

Earlier quoted context omitted.

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

It is basically Modula-2 / Object Pascal with C like syntax. While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases. C++ already prevents many of those scenarios, at least for those folks that don't use it as a plain Better C, and actually make use of the standard library in hardned mode. When not, naturally is…

You would like the T3X language as an exercise to port stuff from Free Pascal too it. In a near future I plan to port two libre text adventures with it, Beyond the Titanic and Supernova. If it fits under T3X, it might run in 'high end' CP/M systems out there.

https://t3x.org/t3x/0/index.html

https://t3x.org/t3x/0/t3xref.html

Beyond these Curses simple games, there's a 6502 assembler and disassembler among a Kim-1 simulator, Micro Common Lisps and whatnot.

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

#309
post #298

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]

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

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

#310

Earlier quoted context omitted.

There are software components out there that are the backbone of our industry, and they are not governed by multibillion dollar companies. Linux, postgres, HTTP, TCP/IP, qemu,… It’s not that anthropic/google/openai/etc are unavoidable

> they are not governed by multibillion dollar companies Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion do…

The usual model for OSS projects is that initially they are written for free. Then an inner circle forms and exploits the second generation of idealists who write entire large features without ever getting the same rights.

Some of the inner circle move to corporations to increase their power and are joined by corporate developers (sometimes their bosses) to take over the project.

A lot of corporate OSS development are entirely unnecessary rewrites or simple things like release management. So I'd put the number of useful code by employees much lower.

But governed, hell yeah, I agree. The corporations crack the whip and oppress real contributors.

Post reply on HN