5 ms·

> We should expect all our languages to be safer. My prediction is modern C++, and even (looking at C23) modern C, will be evolved, albeit gradually, to offer

by _zagj 3y ago

> We should expect all our languages to be safer. 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 https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss

pjmlp 3y ago
C++ is already a much safer C, yet plenty insist in using it like C, full of Cisms. When copy paste compatibility to C is available, only regulated industry practices like MISRA force devs to adopt them.
- PhilipRoman 3y ago
  I don't know about that. The average C++ software is probably safer purely because you can delegate most memory management to standard library. 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.
  - lll-o-lll 3y ago
    So, like Zig then?
  - dannymi 3y ago
    >If Rust had a restricted subset which had a footprint compared to C 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 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/ 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 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).
    - kragen 3y ago
      naïvely, 14 kibibytes sounds like a factor of 2½ worse than c: $ 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 but that's mostly overhead of dietlibc and linux elf rather than overhead of c per se. it's pretty easy to use c to build embedded firmware that fits in 512 or 1024 bytes (though not always advisable) 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
      - steveklabnik 3y ago
        The smallest ELF executable for x86_64 rustc has produced is 138 bytes. You can absolutely get rust code as small as you need, you just have to care enough about binary size to put in the work. We do embedded Rust at work, and do care about this.
        kragen 3y ago
        thank you for the update! what options give the 138-byte executable?
        3y ago
- kragen 3y ago
  c++ is a much less safe c: https://yosefk.com/c++fqa/ https://yosefk.com/c++fqa/
  - pjmlp 3y ago
    So people say, specially C folks.
    - kragen 3y ago
      i have also noted that venezuelans living in argentina are highly critical of the current venezuelan government, while venezuelans living in venezuela have a much wider diversity of opinion on this point
drakmaniso 3y ago
That would only work if the new versions were willing to break backward compatibility. The safety (and correctness) of a language is not about what it can do, but what it cannot.
- berkes 3y ago
  And about what it did in the past. Because that built habits. Has large bodies of education and documentation around it, and often even tooling (like snippets, ai completion, linters, static analysis)
slimsag 3y ago
Also Morello prototype architecture / CHERI could well just end up enforcing this all at the hardware level and make language-level safety a largely moot point.
- MattPalmer1086 3y ago
  Well, if you like crashy programs as opposed to insecure ones, sure! CHERI would stop memory issues being exploited, but it won't make your program work correctly when those same errors are encountered.
  - saagarjha 3y ago
    I don't think there is a language that can guarantee correct operation when you write bugs in it ;)
    - MattPalmer1086 3y ago
      True, but you can use languages that avoid whole classes of bug! 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!
      - slimsag 3y ago
        How far should one go with that line of thinking? 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
        MattPalmer1086 3y ago
        Obviously, you don't need to do that for the majority of things. 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?
pornel 3y ago
I think this is very unlikely to happen. 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. There are safety improvements that C++ could do right now, but is unwilling to do. For example, `[]` on vectors could have bounds checks. `->` on empty `std::optional` could trap instead of being UB. Rust accepts performance cost of these things, C++ doesn't want to. 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.
mamcx 3y ago
That is impossible. 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.

by _zagj 3y ago

pjmlp 3y ago

C++ is already a much safer C, yet plenty insist in using it like C, full of Cisms. When copy paste compatibility to C is available, only regulated industry practices like MISRA force devs to adopt them.

PhilipRoman 3y ago
I don't know about that. The average C++ software is probably safer purely because you can delegate most memory management to standard library. 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.
- lll-o-lll 3y ago
  So, like Zig then?
- dannymi 3y ago
  >If Rust had a restricted subset which had a footprint compared to C 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 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/ 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 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).
  - kragen 3y ago
    naïvely, 14 kibibytes sounds like a factor of 2½ worse than c: $ 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 but that's mostly overhead of dietlibc and linux elf rather than overhead of c per se. it's pretty easy to use c to build embedded firmware that fits in 512 or 1024 bytes (though not always advisable) 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
    - steveklabnik 3y ago
      The smallest ELF executable for x86_64 rustc has produced is 138 bytes. You can absolutely get rust code as small as you need, you just have to care enough about binary size to put in the work. We do embedded Rust at work, and do care about this.
      - kragen 3y ago
        thank you for the update! what options give the 138-byte executable?
        3y ago
kragen 3y ago
c++ is a much less safe c: https://yosefk.com/c++fqa/ https://yosefk.com/c++fqa/
- pjmlp 3y ago
  So people say, specially C folks.
  - kragen 3y ago
    i have also noted that venezuelans living in argentina are highly critical of the current venezuelan government, while venezuelans living in venezuela have a much wider diversity of opinion on this point

drakmaniso 3y ago

That would only work if the new versions were willing to break backward compatibility. The safety (and correctness) of a language is not about what it can do, but what it cannot.

berkes 3y ago
And about what it did in the past. Because that built habits. Has large bodies of education and documentation around it, and often even tooling (like snippets, ai completion, linters, static analysis)

slimsag 3y ago

Also Morello prototype architecture / CHERI could well just end up enforcing this all at the hardware level and make language-level safety a largely moot point.

MattPalmer1086 3y ago
Well, if you like crashy programs as opposed to insecure ones, sure! CHERI would stop memory issues being exploited, but it won't make your program work correctly when those same errors are encountered.
- saagarjha 3y ago
  I don't think there is a language that can guarantee correct operation when you write bugs in it ;)
  - MattPalmer1086 3y ago
    True, but you can use languages that avoid whole classes of bug! 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!
    - slimsag 3y ago
      How far should one go with that line of thinking? 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
      - MattPalmer1086 3y ago
        Obviously, you don't need to do that for the majority of things. 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?

pornel 3y ago

I think this is very unlikely to happen. 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. There are safety improvements that C++ could do right now, but is unwilling to do. For example, `[]` on vectors could have bounds checks. `->` on empty `std::optional` could trap instead of being UB. Rust accepts performance cost of these things, C++ doesn't want to. 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.

mamcx 3y ago

That is impossible. 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.