The case against C in the '20s (was "The Case for Rust (in any system)")

> On Sep 5, 2024, at 11:09 AM, Alan Somers <asomers@FreeBSD.org> wrote:
> 
> By now I expect that most of you have seen the long list of new
> security advisories that just came out.  Strikingly, all were the
> result of memory handling errors.  And none of them wouldn't have
> happened if their respective programs had been written in a
> memory-safe language.
> 
> In fact, of all the C bug fixes that I've been involved with (as
> either author or reviewer) since May, about three quarters could've
> been avoided just by using a better language.
> 
> The real takeaway here is that C is no longer sufficient for writing
> high quality code in the 2020s.  Everyone needs to adapt their tools.
> Programmers who don't will increasingly come to resemble experimental
> archaeologists, i.e. people who learn flintknapping to "keep the
> knowledge alive".  Such people are valuable, but definitely niche.  I
> for one don't want my career to go in that trajectory.
> 
> To summarize, here's the list of this week's security advisories, and
> also some other recent C bug fixes of my own involvement:

First off, I wholeheartedly agree and enjoy Rust, even though I also acknowledge the immaturity of the Rust ecosystem.

That being said…
- I personally think us switching from standard C to modern C++ in _certain_ components could also reduce the likelihood of these issues occurring in the future.
- Using Coverity or other SA tools like llvm scan-build (enabled in CI/triggered by Phabricator?) might have also helped reduce the likelihood of this occurring.

I know I’m diverting the topic and this has probably been hashed out already in the other threads, but I think it’s worth considering as an alternative to binding Rust to FreeBSD (in Rust’s current state/at its current maturity).

Thanks for bringing up this topic (and others for discussing this at length). This is something that’s been important as of late in many security circles (mitigating/reducing "toe stubbing" on common security issues).

Cheers,
-Enji

PS I am having to deal with the whole rolling upgrade bootstrap problem with lang/rust at $work again going from 1.7x.y to 1.80.1. It’s a large resource drain having to rebuild lang/rust from scratch on target systems because our builder nodes don’t support running the prebuilt rust binaries :(. I acknowledge that’s a “$work” problem, but… it’s something that $work frankly doesn’t run into with other languages like golang, Java, perl, python, etc.