alt Hacker NewsThe problem with C - and I'm saying this as a life-long C programmer and not exactly a fan of Rust - is that C is indeed very sharp but it will cut other people just as easily even though they are far downstream of the original programmer, as well as the users of those programs. And it is extremely hard to not accidentally fall for one of the many pitfalls of C.
I've got my own set of restrictions for when I'm coding in C based on many nights spent poring over various pieces of code and trying to find a way to do it better and safer without outright switching languages. I do believe it is possible. But at the end of all that you have essentially redefined the language in a way that probably no other C programmer would like or agree with, and it would still require very good discipline.
So having languages with fewer footguns is good, as long as the lack of one kind of footgun isn't replaced by a other kinds of footguns. It is one of the reasons I'm interested in the FIL-C project.
Fil-C says it doing runtime checks which is fantastic for debug builds (like valgrind) but I worry a bit about performance with that for release builds. Valgrind can be pretty rough!
My personal view is that good C code looks a lot like Rust where ownership is clear and a borrow checker would approve. The mindset that Rust forces you into is the same one you should be using when writing C.
The longer-term concern is that, if you’re spending late nights learning Rust, it’s probably with the borrow checker. Late nights with C, it’s probably with memory management. One of those two is a bit more applicable to understanding computing at a deeper level.