You must log in or register to comment.
Choosing Rust instead of C or C++ for new projects is a rather light decision. But introducing it into or outright replacing legacy codebase with it is a rather phenomenal undertaking. Fish shell was completely rewritten. Linux is introducing it in no trivial way. I wonder if the woes with C/C++ is that bad.
Librsvg did the rewrite incrementally, so you can choose to only use rust for new code in an existing codebase.
Other than having to know Rust, adding Rust to a C code base is not difficult. They play well together.
There is no need to rewrite old code but, once Rust is there, you are free to.
Linux is a bit of a special case as you cannot just blindly use the Rust standard library.
Having to have a Rust tool chain to build with may or may not be an issue.
For some use cases, like BSD or the Linux kernel, platform support is also a consideration.
Fish was rewritten for a different reason. Essentially, fish wanted to do more with threads, and making something that worked well was going to involve a large amount of work to ensure it was safe and correct (you don’t want data races in your shell). The main dev and a lot of the contributors were already familiar with Rust, so it made a lot of sense.
And so far, Linux seems to be taking it really slowly. There are drivers in Rust, as well as an optional scheduler. The main language for kernel development is still C.
Rust may not be the best option for all projects, but it can be integrated in with minimal disruption if projects do find value with it.
For me the biggest issue is all the undefined behaviour and unsafe memory.
Taking a look at libraries everyone uses where there are unsafe memory issues for years until someone finds them shows this quite nicely.
