4 ms·

If you want to have a language be a "C killer" for secure software you need to put a lot of emphasis on simplicity and portability, which are not strengths of R

by ufo 11y ago

If you want to have a language be a "C killer" for secure software you need to put a lot of emphasis on simplicity and portability, which are not strengths of Rust. I think that if you get rid of raw pointers and type casts, you are able to avoid most undefined behavior with dynamic checks: bounds checking, tagged unions, etc. The notable exception is concurrency bugs, which are hard to avoid without a restrictive static analyzer, but I think there is an argument to be made that perhaps the kind of code mr Bernstein wants to write is better off with "boring" sequential algorithms.

steveklabnik 11y ago
One can argue about simplicity, but is there something specific that's non-portable about Rust?
- ufo 11y ago
  Just that Rust is limited to the architectures Clang supports (I don't think we will see people writing competing Rust implementations in their weekends like its possible to do with C). Clang can generate code for lots of architectures but its still a limitation when compared to C's universality. :)
  - steveklabnik 11y ago
    Cool, that's fair. Hopefully someday we will get compilers for more esoteric architectures; we're trying to not tie behavior to LLVM specifically where it doesn't make sense to.
  - eddyb 11y ago
    It's actually LLVM, not Clang (which also uses LLVM). Yes, it would be a tremendous amount of work to write a Rust compiler from scratch, but you can also write a LLVM backend. Not in a weekend, but it's possible. Bonus points for having both rustc and Clang work with it. Alternatively, once the MIR (Mid-level rust IR) work is done, you will be able to write your own lowering code from that to, say, PIC assembly. It won't be optimized and you'll probably output a lot of code (compared to a fully featured GCC backend at -Os), but you would be able to do it in a weekend.
nickpsecurity 11y ago
Nah, that still won't get you anywhere. There's been a ton of C extensions and variants that got no uptake or development despite easy porting. Cyclone comes to mind. C community has refused to adopt safer, predictable approaches to things going back decades. Also, as with most, can't break backward compatibility with any apps doing things in a stupid or dangerous way. So, it isn't happening. Literally need to focus on the people already considering switching from C instead of its fans or heavy users. Plus, next project should consider seemless compatibility with C for piecemeal rewrites.

by ufo 11y ago

steveklabnik 11y ago

One can argue about simplicity, but is there something specific that's non-portable about Rust?

ufo 11y ago
Just that Rust is limited to the architectures Clang supports (I don't think we will see people writing competing Rust implementations in their weekends like its possible to do with C). Clang can generate code for lots of architectures but its still a limitation when compared to C's universality. :)
- steveklabnik 11y ago
  Cool, that's fair. Hopefully someday we will get compilers for more esoteric architectures; we're trying to not tie behavior to LLVM specifically where it doesn't make sense to.
- eddyb 11y ago
  It's actually LLVM, not Clang (which also uses LLVM). Yes, it would be a tremendous amount of work to write a Rust compiler from scratch, but you can also write a LLVM backend. Not in a weekend, but it's possible. Bonus points for having both rustc and Clang work with it. Alternatively, once the MIR (Mid-level rust IR) work is done, you will be able to write your own lowering code from that to, say, PIC assembly. It won't be optimized and you'll probably output a lot of code (compared to a fully featured GCC backend at -Os), but you would be able to do it in a weekend.

nickpsecurity 11y ago

Nah, that still won't get you anywhere. There's been a ton of C extensions and variants that got no uptake or development despite easy porting. Cyclone comes to mind. C community has refused to adopt safer, predictable approaches to things going back decades. Also, as with most, can't break backward compatibility with any apps doing things in a stupid or dangerous way. So, it isn't happening. Literally need to focus on the people already considering switching from C instead of its fans or heavy users. Plus, next project should consider seemless compatibility with C for piecemeal rewrites.