This is remarkable. Man, there are all those ancient things that "we've lost the source code for". One time, in a past job 10 years ago we were reimplementing something that was lost to the sands of time, using an out of date spec it had used. It was such a tedious job with verification but we got there. Amazing how easy that would be today.
Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
121–130 of 754 posts
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#122Earlier quoted context omitted.
Yes indeed. More than 1 million lines of code (including tests) is jumping lots of hoops but with LLMs it's not as painful so you can just ask it to do the hard things. Example of a Claude Code session after 2 hours of "Crunching" that came out without results https://github.com/mohsen1/tsz/pull/4868 (Edit I force pushed to PR to solve the problem, you can see the initial refuse message in the initial version of PR d…
You should try GPT, I’d be really interested to hear if it works better. (Exclusively using GPT for systems work at $DAYJOB, but compare with opus every couple weeks and GPT consistently gives me better results)
OpenAI gave me that 10x boost and used it all already for this week. I'm guessing the last 50 tests is only doable by GPT 5.5 xhigh
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#1236 days of work to do this. Even if it doesn't end up becoming meaningful, it shows just how tokens and work done will be linked now and in the future. It's going to be hard to compete with someone or a company that has more compute. They will just be able to do things you can't.
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…
[dead]
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#124I 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 think it will eventually be its own dialect of English. Telling LLMs what to do is better using not quite normal English and I think this will continue until it isn't recognizable as natural English anymore, but a new fuzzy programming language (probably >1).
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#125What 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?
It means nothing for Zig. Zig isn't even out of beta yet.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#126Earlier quoted context omitted.
Exactly
This is exactly how Anthropic will market this rewrite towards companies thinking about doing more layoffs. 1 person did a rust rewrite that took 6 days that would have taken hundreds of engineers more than a year to do.
> would have taken hundreds of engineers more than a year
This is estimating what, 10 lines per day each? No way translating code is anywhere near that slow.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#127Earlier 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?
The statement “there exists a project where zig led to an extremely high amount of crashes/memory bugs” does not imply “all zig projects have an extremely high amount of crashes/memory bugs”. This is a classic logic problem - eg “there is an orange cat” doesn’t imply “all cats are orange”.
[deleted]
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#128I 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
> 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
Not that it's a particularly accurate stat, but:
https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
119 open, 885 closed
https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
10 open, 46 closed
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#129Earlier quoted context omitted.
When Microsoft rewrote it in go, there was a comment from one of the leads that they chose it over rust because of the similarity in paradigms (garbage collection, etc), and that using rust would've been more difficult, requiring a lot of "hoop jumping". Now that you've done it... Thoughts?
Yes indeed. More than 1 million lines of code (including tests) is jumping lots of hoops but with LLMs it's not as painful so you can just ask it to do the hard things. Example of a Claude Code session after 2 hours of "Crunching" that came out without results https://github.com/mohsen1/tsz/pull/4868 (Edit I force pushed to PR to solve the problem, you can see the initial refuse message in the initial version of PR d…
[deleted]
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#130Earlier 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
You want a better source than the actual author of Bun?
Authors can't exaggerate? Maybe some actual numbers can convince people.