Because that built habits. Has large bodies of education and documentation around it, and often even tooling (like snippets, ai completion, linters, static analysis)
When copy paste compatibility to C is available, only regulated industry practices like MISRA force devs to adopt them.
But I've found C to be much easier to reason about. You can inline all the functions and macros and all that's left is a bunch of pointer assignments and arithmetic. C++ has a much more complicated lifetime model which is surprisingly easy to violate. Combined with templates, it becomes really difficult to dig in.
Due to this, C is much more practical to use with formal verification tools like Frama-C and various model checkers.
If Rust had a restricted subset which had a footprint compared to C and allows formal verification (including functional requirements) I would switch right now.
Take a look at "#![no_std]", a Rust feature.
If you do that, your Rust Hello World program will have 14 kiB (with no linker optimizations).
>and allows formal verification (including functional requirements)
See <https://rust-formal-methods.github.io/tools.html>.
Also, the Rust compiler can be used as a library and you can add whatever checks you want like that. See <https://yoric.github.io/post/uom.rs/> for an example (not used that much).
Also, I like <https://docs.rs/pre/latest/pre/attr.pre.html>. It allows you to define and then mandate specifying textual requirements (in addition to the usual conditionals).
$ cat smallhello.c
#include <unistd.h>
int main()
{
char hello[] = "hello, world\n";
write(1, hello, sizeof hello - 1);
return 0;
}
$ diet gcc -Wl,-z,noseparate-code smallhello.c -o smallhello
$ strip smallhello
$ ls -l smallhello
-rwxr-xr-x 1 user user 4864 Feb 9 06:47 smallhello
$ ./smallhello
hello, world
i would argue that this is 'with no linker optimizations' because -z noseparate-code was the default until a few years ago. linker optimizations can save another 200 bytes or so in this case
note that this is without dynamic linking. there's no giant standard library being swept under the rug here. most of the executable code in the resulting program is _start pulling in stackgap, which calls find_in_auxvec, __libc_open, __libc_read, __libc_close, __setup_tls, getenv, strstr, and finally main, and strstr in turn calls memcmp (as does getenv) and strlen. main() itself is only 61 bytes of code, __libc_write is 6 bytes, mostly a tail call to __unified_syscall, which is 34 bytes. so we're already looking at overhead that's 40 times the size of the hello-world code itself, which rust apparently expands to 100 times?
but possibly not; it's easy to accidentally compile something with c that ends up 14 kilobytes too
but basically c's required runtime is just memset() and memcpy(). everything else only gets invoked if you call it explicitly
> but basically c's required runtime is just memset() and memcpy(). everything else only gets invoked if you call it explicitly
Rust is barely more: https://doc.rust-lang.org/stable/core/
> memcpy, memmove, memset, memcmp, bcmp, strlen
> rust_begin_panic
> rust_eh_personality
CHERI would stop memory issues being exploited, but it won't make your program work correctly when those same errors are encountered.
I guess my only point is that CHERI may protect you from the worst abuse of those bugs, but it still doesn't mean you shouldn't use something that doesn't suffer from them in the first place!
Should we all be using formally verified C that e.g. the aerospace industry uses? It can prevent whole classes of logic bugs that languages like Rust couldn't dream of
My point is much simpler, if you can use something that removes bugs with no appreciable additional effort (or actually less effort), why wouldn't you?
exactly how far that can go is a matter of debate (it clearly cannot cover all possible bugs, because people have legitimate disagreements about whether a given operation is a bug or correct) but it can certainly cover the bugs cheri can detect
The main value of C and C++ is in their backward compatibility. Many projects don't even use current versions the languages, and stick to decades-old subsets instead.
C and C++ move too slowly and are too fragmented and ossified to make a difference in the foreseeable future. They couldn't copy even the easy stuff like Rust's painless dependency management (C++ modules are not going well). Even if a miracle-safety-feature was invented tomorrow, it will take many many years before it goes through cycles of standardization, implementation across vendors, and new compilers being available as a baseline.
Safety improvements won't be a magic compiler flag — C has already deeply invested in analyzers, sanitizers, and fuzzers to improve safety without rewrites. Rust's improvements come from a richer but stricter type system, and that requires refactorings. There are safer C dialects already that have these features, but nobody wants to add lifetime annotations and rewrite their pointer arithmetic to use slices. "Nobody's going to rewrite millions lines of code" applies the same to Safe-C.
But the more Rust-like features they adopt, the easier it will be to automatically convert them to Rust.
C/C++ has DECADES of development with all chances to become good to go ignored. Is CULTURAL.
Look, no even C `if` fall-trough is fixed, and that is probably the easiest thing to fix of all.
Expecting better from them is like expecting fossil fuel companies to be green.
My prediction is modern C++, and even (looking at C23) modern C, will be evolved, albeit gradually, to offer enough of Rust's safety so that on a cost-benefit analysis of either updating an existing C or C++ codebase to its modern, safer dialect or rewriting it in Rust, it will be a no-brainer to stick with C or C++. Rust will ultimately become a marginal language, like (sorry) Zig:
https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss