The C programming language is terrible. I mean, magnificent, too. Much of the world in which we live was built atop C. It is foundational to almost all..
The C programming language is terrible. I mean, magnificent, too. Much of the world in which we live was built atop C. It is foundational to almost all computer programming, both historically and practically; there’s a reason that the curriculum for Xavier Niel’s revolutionary “42” schools begins with students learning how to rewrite standard C library functions from scratch. But C is no longer suitable for this world which C has built.
I mean “terrible” in the “awe-inspiring dread” sense more than the “bad” sense. C has become a monster. It gives its users far too much artillery with which to shoot their feet off. Copious experience has taught us all, the hard way, that it is very difficult, verging on “basically impossible, ” to write extensive amounts of C code that is not riddled with security holes. As I wrote two years ago, in my first Death To C piece:
If you’ re a developer you already know where I’ m going, of course: to tout the virtues of Rust, which is, in fact, a viable C/C++ replacement. Two years ago I suggested that people start writing new low-level coding projects in Rust instead of C. The first rule of holes, after all, is to stop digging.
Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it — slowly, bit by bit — with Rust. Per this excellent Geoffroy Couprie post:
Rust is no a panacea, of course, There are many other valuable approaches to improving software stability and security. (Formal verification, for instance, or the Langsec movement.) But it is a plausible and valuable iterative approach, and we are only going to dig ourselves out of our giant collective security hole iteratively, one shovelful of better code and better tooling at a time. The sooner we start digging, the sooner C will slowly oxidize away.
