3 ms·

You are correct and many Rust developers and contributors are aware of that point, but the OP wants to highlight the often neglected portion of Rust that may ap

You are correct and many Rust developers and contributors are aware of that point, but the OP wants to highlight the often neglected portion of Rust that may appeal to C/C++ users. Not every C/C++ user would move to Rust just for the safety (I did, but their mileages may vary). Some people look for the better abstraction, some look for the performance, and some others look for just fun. Rust is trying to appeal to many of them, not just the paranoid C/C++ developers; I think this article is very adequate for them.

Animats 12y ago
not just the paranoid C/C++ developers You're not paranoid when they're out to get you. The most recent US-CERT advisory: Alert (TA14-300A) Phishing Campaign Linked with “Dyre” Banking Malware (Adobe Reader vulnerability) "...memory corruption vulnerabilities that could lead to code execution". This has been going on for over thirty years. It's time for the suffering to stop.
- pjmlp 12y ago
  The sad part of this whole history is tha thirty years ago, if you didn't had access to an UNIX system, C didn't had any value. Those of us in other systems already had better alternatives, but then UNIX was pushed into the enterprise and succeeded at that, with the outcome of thirty years of buffer overflows.
  - Dewie 12y ago
    And us who were born later than that get taught that C was the only viable and logical option at that time, from a technical standpoint.
    - pjmlp 12y ago
      From people most likely younger than me.
    - Animats 12y ago
      There are a sizable number of programmers who believe a language has to be unsafe to be fast. This is because, for several decades, most compilers with subscript checking were really dumb about it. This started with Berkeley Pascal for BSD, which made a subroutine call for every subscript check and gave Pascal under UNIX a bad name. Good Pascal compilers were hoisting subscript checks out of loops in the 1970s, but not on UNIX. Then there was the C++ approach, trying to do it in templates. That leads to dumb subscript checking, because the compiler has no idea that the "if" involved in subscript checking is a subscript check and could potentially be hoisted out of the loop and done once at loop entry. For most math code, where this really matters, you can do one check at the top of the loop. Maybe zero checks, if the upper bound is coming from some "range" or "len" construct. At last, smart subscript checking is coming back. This is partly because languages now usually have a "do this to all that stuff" construct ("for i in foo ..." or similar) and it's a no-brainer that you don't need to check subscripts on every iteration. The Go compiler at least has that. How smart is the Rust compiler about this? It potentially could be very smart. This is important. Otherwise, people will want to turn subscript checks off for "performance".
      - Dewie 12y ago
        It's idiomatic in rust to use iterators rather than loops. When it comes to iterators that for example iterate over a vector/array, there is no bounds-checking. I don't know if that is implemented by explicitly opting out of the bounds checking in the implementation of the iterator, or by some other means. In either case, bounds checking is turned off when the "looping" is encapsulated in iterators, but not for arbitrary indexing (which is a good reason not to use explicit indexing when you don't have to, of course).
  - tormeh 12y ago
    What were the better alternatives?
    - pjmlp 12y ago
      Algol variants, PL variants, Extended Pascal, Modula-2, Mesa, Cedar, ...

Animats 12y ago

not just the paranoid C/C++ developers You're not paranoid when they're out to get you. The most recent US-CERT advisory: Alert (TA14-300A) Phishing Campaign Linked with “Dyre” Banking Malware (Adobe Reader vulnerability) "...memory corruption vulnerabilities that could lead to code execution". This has been going on for over thirty years. It's time for the suffering to stop.

pjmlp 12y ago
The sad part of this whole history is tha thirty years ago, if you didn't had access to an UNIX system, C didn't had any value. Those of us in other systems already had better alternatives, but then UNIX was pushed into the enterprise and succeeded at that, with the outcome of thirty years of buffer overflows.
- Dewie 12y ago
  And us who were born later than that get taught that C was the only viable and logical option at that time, from a technical standpoint.
  - pjmlp 12y ago
    From people most likely younger than me.
  - Animats 12y ago
    There are a sizable number of programmers who believe a language has to be unsafe to be fast. This is because, for several decades, most compilers with subscript checking were really dumb about it. This started with Berkeley Pascal for BSD, which made a subroutine call for every subscript check and gave Pascal under UNIX a bad name. Good Pascal compilers were hoisting subscript checks out of loops in the 1970s, but not on UNIX. Then there was the C++ approach, trying to do it in templates. That leads to dumb subscript checking, because the compiler has no idea that the "if" involved in subscript checking is a subscript check and could potentially be hoisted out of the loop and done once at loop entry. For most math code, where this really matters, you can do one check at the top of the loop. Maybe zero checks, if the upper bound is coming from some "range" or "len" construct. At last, smart subscript checking is coming back. This is partly because languages now usually have a "do this to all that stuff" construct ("for i in foo ..." or similar) and it's a no-brainer that you don't need to check subscripts on every iteration. The Go compiler at least has that. How smart is the Rust compiler about this? It potentially could be very smart. This is important. Otherwise, people will want to turn subscript checks off for "performance".
    - Dewie 12y ago
      It's idiomatic in rust to use iterators rather than loops. When it comes to iterators that for example iterate over a vector/array, there is no bounds-checking. I don't know if that is implemented by explicitly opting out of the bounds checking in the implementation of the iterator, or by some other means. In either case, bounds checking is turned off when the "looping" is encapsulated in iterators, but not for arbitrary indexing (which is a good reason not to use explicit indexing when you don't have to, of course).
- tormeh 12y ago
  What were the better alternatives?
  - pjmlp 12y ago
    Algol variants, PL variants, Extended Pascal, Modula-2, Mesa, Cedar, ...