6 ms·

Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers,

Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.

deleted 11y ago
[deleted]
qznc 11y ago
Rust also has nearly no runtime and no garbage collector. Lack of GC makes it possible to integrate a Rust library into scripting languages etc. This is an easier upgrade path from C, which D, Go, Nim, etc cannot provide. (For my projects I prefer D, but Rust has a point here)
- nyan4 11y ago
  Nim GC is optional; It can be disabled to write system libraries.
deleted 11y ago
[deleted]
denim_chicken 11y ago
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."
  - 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.

deleted 11y ago

[deleted]

qznc 11y ago

Rust also has nearly no runtime and no garbage collector. Lack of GC makes it possible to integrate a Rust library into scripting languages etc. This is an easier upgrade path from C, which D, Go, Nim, etc cannot provide. (For my projects I prefer D, but Rust has a point here)

nyan4 11y ago
Nim GC is optional; It can be disabled to write system libraries.

deleted 11y ago

[deleted]

denim_chicken 11y ago

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."
- 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.