5 ms·

Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.

by denim_chicken 11y ago

ufo 11y ago
C++ is not reasonable if your goal is to avoid memory safety bugs.
- denim_chicken 11y ago
  Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust. There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc development and especially fuzz testing. I bet there are only 1-2 developers who work on glibc full-time.
  - mikeash 11y ago
    Has there been any work on a safe C? Not a C-ish language that is safe, but an actual implementation of the C language itself. The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility? Some of this already exists, with stuff like stack canaries and address sanitizer. But can it go beyond these ad hoc solutions that catch common mishaps, and become something truly reliable? It should be possible to just flip a switch on the compiler and have it so that, for example, if you alloca() X bytes and then use the resulting pointer to access byte X+1, that is reliably caught at runtime. And not just as some single patch that specifically looks out for alloca() abuse, but as part of a wider system that understands and catches all out of bounds access.
    - steveklabnik 11y ago
      This is sort of what Cyclone tried, in a way.
      - mikeash 11y ago
        Cyclone looks cool, but it's a pretty significant departure from normal C. I'm wondering how far you can take safety without changing the actual language at all. Or rather, how far you can take safety without changing the language and without completely killing performance. Memory safety shouldn't be hard: track all valid regions and pointers to them and don't allow mixing stuff up. But doing it fast is tough.
    - GregBuchholz 11y ago
      Have you looked at CCured? http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf "CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."
      - mikeash 11y ago
        I haven't heard of it before, but that's the sort of thing I'm thinking of, and that looks pretty cool. Looks like the resulting programs still perform reasonably well too.
  - openasocket 11y ago
    FYI, Rust has no more of a runtime system than C/C++.
  - arielb1 11y ago
    Rust does not really have an RTS per se. libstd is just a standard library. Also, even if rustc has soundness bugs, you won't find them if you don't look for them, and even then, just trying to make your program fit the types will prevent most bugs. By the way, glibc's code is too horrible to be read - musl is a more modern alternative.
    - h3st 11y ago
      > Rust does not really have an RTS per se. libstd is just a standard library. And if you don't want to use the standard library, you just say #![no_std] https://doc.rust-lang.org/stable/book/using-rust-without-the-standard-library.html https://doc.rust-lang.org/stable/book/using-rust-without-the...
  - AsyncAwait 11y ago
    That doesn't mean sticking with the status-quo is the solution. Rust certainly looks like a better starting point for modern, safe low-level programming than C. C served us quite well for over 40 years, but perhaps it's time to move on...
- aikah 11y ago
  > C++ is not reasonable if your goal is to avoid memory safety bugs. I'll get crucified for saying this but it's easier to write safe code in C++ than C. C requires a perfect discipline very few people can maintain. Cyclone-lang had good ideas about how to fix C, almost 10 years ago. I wish it has been more successful. i was less "alien" looking than Rust.
  - pjmlp 11y ago
    True, and hence why my rants about C tend to kind of ignore C++, as the community is more safe aware and strives to avoid the C compatibility subset. However, it is very hard to avoid C++ developers that don't follow the modern C++ mantra to use it as if it was C, specially in the enterprise space. You end up with "C compiled with C++" code style, which usually isn't subjected to any kind of code reviews or static analysis.
pyre 11y ago
At what point will people consider Rust mature enough though? If we're going on number of years in existence, then C will always be older than Rust and the "well it's more 'battle-tested'" argument will never be false (for any language that is currently younger than C).
- denim_chicken 11y ago
  Maybe in a decade.
  - yazaddaruvala 11y ago
    Do you not use git, because it hasn't been a decade? Will you only start using it after April 7th? I've heard someone in real life say "git just isn't there yet", so I couldn't resist humoring myself with this comment, sorry.

Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.

ufo 11y ago

C++ is not reasonable if your goal is to avoid memory safety bugs.

denim_chicken 11y ago
Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust. There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc development and especially fuzz testing. I bet there are only 1-2 developers who work on glibc full-time.
- mikeash 11y ago
  Has there been any work on a safe C? Not a C-ish language that is safe, but an actual implementation of the C language itself. The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility? Some of this already exists, with stuff like stack canaries and address sanitizer. But can it go beyond these ad hoc solutions that catch common mishaps, and become something truly reliable? It should be possible to just flip a switch on the compiler and have it so that, for example, if you alloca() X bytes and then use the resulting pointer to access byte X+1, that is reliably caught at runtime. And not just as some single patch that specifically looks out for alloca() abuse, but as part of a wider system that understands and catches all out of bounds access.
  - steveklabnik 11y ago
    This is sort of what Cyclone tried, in a way.
    - mikeash 11y ago
      Cyclone looks cool, but it's a pretty significant departure from normal C. I'm wondering how far you can take safety without changing the actual language at all. Or rather, how far you can take safety without changing the language and without completely killing performance. Memory safety shouldn't be hard: track all valid regions and pointers to them and don't allow mixing stuff up. But doing it fast is tough.
  - GregBuchholz 11y ago
    Have you looked at CCured? http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf "CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."
    - mikeash 11y ago
      I haven't heard of it before, but that's the sort of thing I'm thinking of, and that looks pretty cool. Looks like the resulting programs still perform reasonably well too.
- openasocket 11y ago
  FYI, Rust has no more of a runtime system than C/C++.
- arielb1 11y ago
  Rust does not really have an RTS per se. libstd is just a standard library. Also, even if rustc has soundness bugs, you won't find them if you don't look for them, and even then, just trying to make your program fit the types will prevent most bugs. By the way, glibc's code is too horrible to be read - musl is a more modern alternative.
  - h3st 11y ago
    > Rust does not really have an RTS per se. libstd is just a standard library. And if you don't want to use the standard library, you just say #![no_std] https://doc.rust-lang.org/stable/book/using-rust-without-the-standard-library.html https://doc.rust-lang.org/stable/book/using-rust-without-the...
- AsyncAwait 11y ago
  That doesn't mean sticking with the status-quo is the solution. Rust certainly looks like a better starting point for modern, safe low-level programming than C. C served us quite well for over 40 years, but perhaps it's time to move on...
aikah 11y ago
> C++ is not reasonable if your goal is to avoid memory safety bugs. I'll get crucified for saying this but it's easier to write safe code in C++ than C. C requires a perfect discipline very few people can maintain. Cyclone-lang had good ideas about how to fix C, almost 10 years ago. I wish it has been more successful. i was less "alien" looking than Rust.
- pjmlp 11y ago
  True, and hence why my rants about C tend to kind of ignore C++, as the community is more safe aware and strives to avoid the C compatibility subset. However, it is very hard to avoid C++ developers that don't follow the modern C++ mantra to use it as if it was C, specially in the enterprise space. You end up with "C compiled with C++" code style, which usually isn't subjected to any kind of code reviews or static analysis.

pyre 11y ago

At what point will people consider Rust mature enough though? If we're going on number of years in existence, then C will always be older than Rust and the "well it's more 'battle-tested'" argument will never be false (for any language that is currently younger than C).

denim_chicken 11y ago
Maybe in a decade.
- yazaddaruvala 11y ago
  Do you not use git, because it hasn't been a decade? Will you only start using it after April 7th? I've heard someone in real life say "git just isn't there yet", so I couldn't resist humoring myself with this comment, sorry.