I used to like rust, but I feel like I’m being Pavlovian-conditioned to recoil at its mention now.
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
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.
Likewise, you could ignore his comment but decided to engage.
Because I don't think this. A rewrite is cheaper to me.
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.
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...
Kinda like jackass, fascinating to watch but damn I do not want to do it
Atleast people aren't AI rewriting things into PHP.
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.
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.
> I could rewrite anything in unsafe Rust like right now, despite being a novice in the language.
I really doubt that. Unsafe Rust is actually significantly more difficult to get right than C or C++. See e.g. https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ or https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
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).
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.
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.
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.
Yes it is.
> In many aspect, it is worse.
"Many"? Compilation time sure. That's about it. Anyway things don't have to be pareto better to be better. A car is better than a horse, even though it can't travel over rough terrain as easily.
> 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.
Memory safety is far from its only advantage over C. The fact that you think that is a strong signal you haven't ever seriously tried it.
> Also the supply chain risks in the Rust ecosystem are worrying.
What language is xz written in again?
> I also think that Rust is somewhat poorly designed in this regard compared to what is possible here
I disagree. Sure there are fancier type systems (Idris, Haskell, etc.), but they also have downsides. In any case we're comparing C and Rust. Rust is clearly way ahead of Rust. Your argument is "washing machines aren't better than hand washing because they don't also fold your clothes!"
xz was a highly sophisticated attack using social engineering and hiding malware in build artifacts, and it was found just in time. It has nothing to do with languages (it was not obfuscated C or something), but highlights that one has to carefully protect the supply chain. There were several compromised packages in cargo already, Rustup teaches people to do curl | sh.
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.
Rust is not just C with memory safety!!