On the one side I really like c and c++ because theyβre fun and have great performance; they donβt feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift).
On the other hand, when weighing oneβs feelings against the common good, I guess itβs not really a contest. Plus I suspect a lot of my annoyance with languages like rust stems from not being as familiar with the paradigm. What do you all think?
You donβt have to ban C or C++; you just have to prove your programs are memory safe. Itβs been decades since Iβve coded in C, but surely Valgrind and ilk are now capable of providing reasonable proof of memory safety. You might have to turn up all the dials and set all-warnings-are-errors, but Iβd be surprised if C tooling wasnβt available to provide sufficient proof for a given statically-linked program.
Iβd be surprised if C tooling wasnβt available to provide sufficient proof for a given statically-linked program.
Be prepared to be surprised then. If such tooling was available, why isnβt it being used by the projects for whom it matters? Yes, there is tooling available, but all the big parties using them are admitting itβs not good enough for them. Those tools help, but they do fail in the βsufficient proofβ department.
For some follow-up reading:
- Microsoft: https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-systems-programming/
- Chromium: https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html
- Android: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
- Apple: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/
They all share the same basic facts: C and C++ are inherently memory unsafe. If any of them couldβve βjust prove[n] your programs are memory safeβ, I think they would have.
If such tooling was available, why isnβt it being used by the projects for whom it matters
Oh, my dear, sweet, summer child. Welcome to capitalism, and the rule of βgood enough.β Static code analysis tools cost money, and take time to run. Iβve yet to work at a company that didnβt have a documented process for entirely bypassing QA in urgent situations; although, when I contracted with the USFS, they were much more reluctant to cut corners - that was under a Democrat president; when Republicans took charge, they cut a lot of things, including software quality controls.
But - as I said - I havenβt touched C in decades, so I canβt refute your claim that such tools donβt exist.
Nothing, and certainly not Rust, is βperfectlyβ memory safe. You get closer with Haskell. At some point, you define what βgood enoughβ is, and itβs up to languages to provide tooling to either meet those standards (and be approved), or donβt.
Granted, itβd be far harder for, say, Ruby to meet those proofs than a language like Rust, but the critical point is to have a defined standard of βgood enoughβ for languages to work towards.