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!!