With composable I mean the ease in which you can include a external library without having to study it first. Whenever I had to use C this was always a bottleneck and you resort to copy paste hell, with slight changes to the original source.
With composable I mean the ease in which you can include a external library without having to study it first. Whenever I had to use C this was always a bottleneck and you resort to copy paste hell, with slight changes to the original source.
Having existing C codebases in production which are time-tested and stable and reliable is a huge advantage of having to rewrite them from scratch, don't you think?
Also, you can check out C code from 20 years ago and build it in your personal laptop with ease, and be able to do the exact same thing 20 years from now. Meanwhile, Rust still fails to put together a single specification, let alone a standard one, and relies on reference implementations that may or may not exist in a few years.
I'm an advocate of Rust for most software, mind you. The safety you get from enforcing ownership at function and crate boundaries is allowing the package ecosystem to grow rapidly at a high quality. The safety win partially mitigates the safety loss you get from adopting hundreds of small transitive dependencies maintained by random people on the internet. But if you've spend tens of thousands of dollars having engineers test and validate some piece of safety critical code, you're going to need a really good business case for touching it at all.
That advantage may be temporary.
Language stability, tons of tooling, validation, decades of experience, plus the fact that you might have spent 500 million dollars to develop your existing codebase.
Not to mention Rust is still a moving target and it's not ratified for safety-critical uses.