Seriously though, as others are saying sarcastically, I'll join them right up: "C is completely fine, you are just doing it wrong, it's a safe language when you know what you are doing".
Yeah, about that. <Glances the article again>
It's not a matter of "if", guys. It's only a matter of "when".
No, not yet. The Rust ecosystem is still not mature enough. One of the big problems is Cargo which sidesteps distro packaging and pulls dependencies from some random server. This doesn't fly if you actually want reproducible builds. The other problems are the complete disregard for dynamic linking and the amount of churn in the standard library and compiler. Give Rust a few more years for things to stabilize and for people to figure out a reasonable way to handle these problems. The work will probably fall on the distro maintainers.
My opinion is that if you're looking for a short-term investment that someone might want to make towards fixing these problems, try working on static analysis security tools for C and C++. It could not be easier to make these now with libclang. Alternatively, maybe get your company to fund a purchase of PVS-Studio or something like that.
So no, Cargo doesn't "sidestep" distribution packaging, it works with distribution packaging.
Also, neither the standard library nor the compiler have "churn"; we're very careful to make sure old code still compiles with current Rust.
>Also, neither the standard library nor the compiler have "churn"; we're very careful to make sure old code still compiles with current Rust.
When did this happen? Last I checked Rust still had no LTS policy and there were no stability guarantees around the syntax, ABI, API, compiler flags, Cargo file format, etc. If some policy has changed here, please link me to any info.
Just to reiterate: I wrote the initial prototype, and massive credit goes to the current maintainers who picked it up and ran with it into production.
> there were no stability guarantees around the syntax, ABI, API, compiler flags, Cargo file format, etc.
There are absolutely stability guarantees around syntax, around compiler flags, around API, and around the Cargo file format. Code from old Rust and old Cargo will build and run with new Rust and new Cargo. We take a great deal of care to preserve that stability guarantee. The policies here have remained essentially the same since 1.0 (https://blog.rust-lang.org/2014/10/30/Stability.html), though we've since taken further care to specify them more precisely and to stabilize further areas.
(Source: I'm one of the leads of the Rust language team, and I'm on the Rust cargo team. Other Rust teams, such as the Rust library team, follow the same principles.)
https://www.pietroalbini.org/blog/shipping-a-compiler-every-...
https://blog.ryanlevick.com/rust-2020/
Disclosure, I don't work on Rust or any other language, I just keep an eye on it out of interest. I give it another few years before these big regressions stop happening. Please keep at it and don't take any of my statements as being discouraging.
https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_ty...
That query lists all regressions filed in the last 6 weeks, and there are nearly 150 of them.
There's active work on Rust specifications with varying degrees of formality, but I don't think that would address the problem you're describing. Specifications don't make bugs go away.
There are, occasionally, regressions in rustc. We catch the vast majority of those before they hit the stable branch, but bugs do happen. We try to minimize them, and we also put out stable point releases with fixes.
I also don't think that having multiple Rust compilers would affect the problem you're talking about. On the contrary, you'd then have multiple different sets of occasional bugs to deal with, and multiple implementations with differences that you'd have to cope with.
Speaking personally, (and not wearing my language team hat), I personally don't see value in having multiple compiler frontends for Rust, given that rustc is Open Source. (I absolutely see value in having multiple code generation backends, but not in having multiple frontends.)
Finally, regarding an "LTS" release: stable releases of Rust are supposed to be stable, not stagnant.
As well, pulling from a random server isn't the problem. Trusting a version to be a particular commit is, which crates.io handles as well as Cargo via cargo publish and the lock file. If you pull a dep, the lock file will guarantee that whatever you pull is going to be identical to what was published (assuming you didn't add a git field to the dependencies list or say version = "*").
As for churn in the std or dynamic linking, I've never had an issue using Rust in production and getting reproducible builds otherwise. Same is true for Clang or GCC/stdlib. APIs aren't being changed, binaries may shift, but unless you're on nightly you're probably not going to see anything break - just get better. But you can handle that, just don't update the compiler until you're ready.
Oracle has SPARC ADI, ARM MTE (now adopted by iOS, in the future Android as well), because the only way to have those magical excellent C coders, is to have the hardware be their tiny wheels.
I'm not really that concerned about C so I won't be able to fund the efforts, but I'm sure once you have a bootable operating system that works with existing software that people will be willing to donate to you on Patreon.