Someone is having fun with a side experiment that has no practical real-world implications.
This stuff is supposed to be fun and we should celebrate when other people are doing fun, pointless things like this. If you're interested then ignore it and move on. There's no need to get involved or comment if a project of no consequence is uninteresting to you personally
Bun was originally written in Zig. It was one of the Zig language’s flagship projects that was brought up everywhere as an example of a successful Zig project, alongside Tiger Beetle and Ghostty.
The Bun team did an experiment to have an LLM transliterate the codebase to Rust and then iterate on turning it into idiomatic Rust. They were losing a lot of time dealing with memory management problems and wanted to move to a language with more memory safety built in rather than Zig’s very manual cleanup, which is challenging in a project like Bun that is dealing with running another language.
The Bun team posted a small blog post about the migration with technical details about how they’re doing it, along with some thanks to the Zig team and positive notes about Zig. The Zig language creator posted a blog post where he ranted about the Bun creator writing “slop before LLMs” and being a “stinky manager” according to “juicy grapes” he heard through the grapevine and numerous other attacks. It was an emotionally charged response to one of the language’s flagship projects leaving for another language.
This split the community, or at least became divisive for a lot of people who have no interest in Bun but view the fight as a proxy for some other battle like hating LLMs or Rust.
It didn’t actually kill the project. The team was acquired by Anthropic and it (the Rust version) is being used in their products, so it’s actually running everywhere and doing more than ever. There was a poll on some subreddit that showed only 30% of people were going to keep using it after the rewrite and people keep holding this up as evidence that the project is dead.
I have the opposite feeling; I am liking Rust more and more and thinking most of the world's C code should be rewritten. It seems like a sweet spot of enforced memory safety, performance, and human/agent readability.
I think Rust is annoyingly complex and badly designed (although it has good parts) and this would be the same mistake as past pushs to move projects to C++ because "object orientation is clearly better", and as such also step towards more complexity that is difficult to undo again and therefor actively harmful. The better and more powerful approach to safety is proving correctness, which is already possible today but we lack good opensource tooling. Proofs can be added to existing code without introducing complexity.
Rust and C++'s overcomplex syntax are a nightmare to maintain and set.
Go should have been the C succesor long ago, at least for 64 bit machines.
In the end It's from the same people of Unix/C/Plan9, so they know their
flaws and reasons.
For C++ like performance, sadly there's nothing close to Rust, but Zig and Nim can be close
and good enough. Inb4 "mah objects", just use Java or C# and forget C++ forever for
OOP programming. The sooner, the better.
If you like using C++ just as an improved C and hate templates and
objects, just use it for QT5/6 and some performing games and applications.
Go can handle the rest just fine.
What I'd love is to see projects like Cataclysm DDA:Bright Nights rewritten in Go, they could save tons of issues on compiling (Clang 11 here, a nightmware to compile) and running, because for an open world game
using the GC would free tons of waste on references and objects ingame.
Also it will compile much faster and it could be ported to most platforms
with no efforts at all.
And I say this as an ScummVM user and sometimes I like debugging some old adventure and RPG games under it...
Memory bugs are unknown unknowns that AI may or may not catch. There's net-present-value in switching to a language where certain types of memory bugs are impossible.
On the contrary, AI agents are doing an outstanding job of catching and fixing them. The jury's still out on the cost-to-value ratio of improving existing code vs. rewriting it.
I think Rust (the compiler / borrow checker) kinda finds bugs for you, some of which C/C++ does not.
In that sense, rewriting some code in Rust _may_ be cheaper than fixing the existing code. It may also be more welcoming to newer devs, since Rust can be easier to reason about, which is a long-term investment.
The borrow checker also helps with AI (as long as you don't let the AI use `unsafe`, or completely control what primitives in your codebase are allowed to use unsafe and never vibe-code any of it) — at least, the agent can't stop until `cargo build` passes.
I've also had better experience locally building applications in Rust than in C/C++. `cd ripgrep; cargo install --path .` or `cargo install ripgrep` usually just work, while `make` is usually painful.
I guess ask the bun people why they translated from zig to rust. I think it was essentially because rust guarantees a set of bugs can't exist so over medium to long term timeframes you end up with less technical debt.
Because making segfaults impossible is simply a better solution to playing a game of whack a mole of "crash, root cause, fix and add test for that very specific bug"?
I'd prefer reading about a rust rewrite then a saas paas CMS integration web thing on the latest framework
It'll probably go nowhere, but it's cool to see people test the limits of what they can do and I can't watch without spending a penny
Kinda like jackass, fascinating to watch but damn I do not want to do it
It's pretty much the standard target for slop now, so now "in Rust" kind of implies "I just pointed Claude at it and have no idea if the result is any good, also it's an abandoned project."
Tbh I think Rust is popular and mainstream enough that it doesn't matter too much. There are still plenty of great Rust projects out there.
Truly, is that Rust's fault that sloppers are targeting it?
Personally I'm becoming increasingly disillusioned with current LLMs' capabilities. All those recent high profile "rewrites" turned out to be transliterations to unsafe Rust.
I could rewrite anything in unsafe Rust like right now, despite being a novice in the language.
That's not quite true. I had a look into the Bun port and it's not like c2rust where it literally will convert every pointer access into `unsafe` and 50% of your code will be `unsafe`. It's a lot safer than that. They claim only 4% of lines are unsafe, and 78% of those are from C/C++ interop. That's more than a typical Rust project but it's still a lot less than C/C++ or Zig.
> I could rewrite anything in unsafe Rust like right now, despite being a novice in the language.
It's not too big of a deal because in idiomatic Rust you pretty much never write unsafe code (except for FFI), but it would be nice if it was not quite so hard (or poorly defined).
> Truly, is that Rust's fault that sloppers are targeting it?
The "Rewrite it in Rust!", all gas, no brakes zealotry predates LLM coding agents. When you dismiss the trade-offs with no consideration, and abide no questions about the possible cost of the "one true $X", you're practicing religion, not engineering. What has changed is the zealots no longer restricted to demanding that other people adapt their preferred language, but can now automate forking projects into their ideal language. I'm hoping the next shoe to drop is the realization that the language is a small part of a projects success, when it's time to maintain their forks.
Rewrite it in Rust isn't zealotry with no consideration of the trade-offs. It's simply that Rust is so much better than C that it's pretty much a no-brainer to rewrite C in Rust, or at least to attempt it.
Sorry you can't see a good thing for what it is.
> the language is a small part of a projects success
Perhaps, but it is still a part of a project's success. Many projects written in PHP or Ruby or something other sub-par language have succeeded in spite of that, of course. But plenty have failed that might otherwise have succeeded because of that too. For example Mercurial.
Rust is not a lot better than C. In many aspect, it is worse. It is better if you focus on a specific point (memory safety) and exaggerate its importance beyond all other considerations and ignoring all other options to make progress in this area. This is the zealotry part.
For my personal IT security, people pushing Rust made things worse not better as I do not get security updates for parts of my OS (Debian) anymore. Also the supply chain risks in the Rust ecosystem are worrying. So even if you go the overall topic security rather than just memory safety, the situation is not all that clear anymore.
It is, of course, in the best interest of Google and co., who are in the business of putting spyware and locked-down content-distribution systems in everybody's pocket, to fully focus on memory safety. Not so much for the free software community where supply chain, long-term maintenance, and the health of existing projects and communities are more important.
And just to preempt the argument "but the superior type system will make everything better". I also was super excited about type system in my youth. I get why people are exited about this. But with experience I realized this also fairly easy to overestimate the impact of this (as I did myself). I also think that Rust is somewhat poorly designed in this regard compared to what is possible here, and adopting it makes it harder to adopt truly better techniques.
> [...]it's pretty much a no-brainer to rewrite C in Rust, or at least to attempt it.
Thank you for proving my point. To be clear: there are a lot of legitimate reasons to not rewrite a C projects in Rust, memory safety isn't a universal trump card that supercedes all other considerations in all projects; one has to be zealot to believe that.
I suspect the majority of Rust users are rational about when Rust is appropriate (or not), but they are not going around in random bug threads demanding rewrites of multi-decade projects.
Someone is having fun with a side experiment that has no practical real-world implications.
This stuff is supposed to be fun and we should celebrate when other people are doing fun, pointless things like this. If you're interested then ignore it and move on. There's no need to get involved or comment if a project of no consequence is uninteresting to you personally