"There are safe languages that are similar enough to C that it is not hard to pick them up for a C programmer." It's not about similarity, it's about differenc

"There are safe languages that are similar enough to C that it is not hard to pick them up for a C programmer." It's not about similarity, it's about differences. System code is all about subtleties in language, UBs in C for example. Just because Rust syntax is similar doesn't mean it can be easily picked up by a C dev. "Rust is almost runtime-less." Almost is the key. Even FAQ mentions that it's not suitable for low level code exactly because of its assumptions about how memory allocator works. You'd have to implement it. And you still assume that compiler output is flawless (which is very unlikely given Rust's age). "I didn't say it's not going to be work :)" But that's exactly what you're implying ;P "Oh come on, it can be done, why not?!" I'm giving you reasons why. These aren't superficial, I worked on OS, OS drivers, I'm currently working on hardware simulators. If your aim is safer systems, switching from C to Rust (which I happen to love) isn't the answer yet. And probably not for the next 10+ years. "That does not mean that, say, Haskell is not tremendously much safer than C." I'm not saying that there are no languages inherently safer than C. I'm saying that a) people can't switch just like that, b) familiar syntax isn't enough, c) legacy matters, d) there's always something that will still be "unsafe". As a pragmatic I'm claiming that you can spend time better than switching languages. "First, because you only have to implement the icky parts once." How is this not true in C? "Second, because a better type system and abolishment of undefined behaviour gives you more safety for a very small cost (if at all, the extra compile time for a better type system is probably negated by the cost of headers)." No, again, cost associated with new language is massive, especially if you care about quality.