The Ubutnu coreutils thing last week really soured me on 99.8% test compatibility Rust rewrites :|. I clicked through to the tweet linked here and it was kind of like shudder I feel quite opposite now when I see this kind of thing. I'm like *looking for exit*
Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
321–330 of 754 posts
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#322Earlier 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…
Thank you for actually making the effort to respond to the curiosity in my question.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#323So 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 build a mental model of fresh 1m code in 6 days.
This is code for a language runtime.
It's great that the tests pass but it's really hard for me to interpret this as anything other than horrible mismanagement of a promising project. When you sit this low in the stack this is grossly irresponsible and I have no idea why anyone would use Bun after this. You'd be literally adopting a runtime the devs presumably don't understand, keep in mind they now somehow need to evolve and maintain this in the future.
Hopefully this remains an experiment, or Bun has some plan for re-upping dev knowledge of the codebase. Sorry but a component with massive blast radius like a runtime isn't really a good candidate for vibe coding, no matter how good the AI is. I'd like the maintainers to actually understand their runtime, thanks.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#324I think a lot of people taking this at face value , a lot of this was possible because of the beyond standard extensive and comprehensive test suit previously built.
If this is a "beyond standard" test suite, (so much so that it _uniquely_ makes this work possible compared to other projects,) then how is Bun also uniquely unstable compared to other Zig programs (and so deserving of rewrite?) If the blame lies partially with the test suite, what does this imply (if anything) about the Rust port?
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#325Completely 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…
[deleted]
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#326Were there perhaps [licensing issues](https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense) with the original?
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#327Earlier quoted context omitted.
Zig is a great low-level language. It's much better than C, while not being so much larger as e.g. Rust or C++. AFAICT Zig does well in embedded development, and should continue to do so. Note that Zig is not even 1.0 yet.
Yeah but now they got the fame of the language that fumbled the ball because of an overly onerous anti-AI stance.
They haven't fumbled anything. One person has used AI to vibe code a rewrite of a Zig program in another language. Zig didn't gain popularity due to Bun, last I checked Bun doesn't even mention it is written in Zig on the homepage. Zig is appreciate for major improvements over C, while being simple and concise.
In addition, a core Zig developer has explained why the PR was rejected, because it would introduce non-deterministic bugs into the compiler, just to achieve a speedup Zig is already gaining thanks to recent work on the self-hosted backend and incremental compilation, which are far more general as well.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#328Earlier quoted context omitted.
cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.
Rust is really fun to work with and the compiler is great, just make sure the rewrite takes compile times into account since larger projects often have to be organized in a way that makes compilation reasonably fast.
In my experience Bun in Zig compiles more slowly than Deno in Rust.
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#329Earlier quoted context omitted.
Look what it can do in 6 days! Ignore the hundreds of thousands of hours put into the original architecture and test suite that made it possible in the first place.
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..
I disagree with calling this bad faith. For instance:
* I can agive you one quarter of amazing profits, if you let me dismantle and sell all the assets of a company.
* I can give you a few years of incredible food production, if you let me strip a rainforest and plant commercial crops.
* I can give you incredibly cheap energy, if you let me mine non renewing fossil fuels from the earth.
The context of why something is possible matters. In this case, because a very large and comprehensive test suite was seen as a necessity to specify a successful project (managed by humans). I do not believe a LLM coded project could ever have made such a test suite. In this case, the LLM is consuming the result of expensive human labor (the test suite) to make what ultimately is a minor variation to it (the implementation language).
Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc
#330Earlier quoted context omitted.
Fwiw you don't need unsafe for graphs or linked lists in Rust. At least not directly - these things can be abstracted. The petgraph crate is the most popular for graphs. I'm not sure about linked lists because linked lists are the wrong choice 99.9% of the time. I've written hundreds of thousands of lines of Rust and outside of FFI, I've written I think one line of unsafe Rust.
[flagged]
Not really though. That's like saying that no language is "safe" because the compiler could have a bug.
It's true that safe wrappers around unsafe code sometimes have bugs in them, but it's orders of magnitude easier to get the abstraction right once than to use unsafe correctly in many places sprawled across a large codebase.