8 ms·

I arrived to the comments section before the C vs Rust flame war

pjmlp 11y ago
Don't bother, they haven't learned about writing secure code since Extended Algol (1961), Mesa (early 70's), Modula-2 (1978), Cedar (early 80's), Ada (1983), Oberon (1991),... anyway.
- tosseraccount 11y ago
  17 years ago it was "Let's rewrite Unix in Perl" ... http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl I do wish them the best luck, though.
  - jest3r1 11y ago
    Strange to go back in time.
- cwzwarich 11y ago
  Aren't Cedar and Oberon are the only languages in that list that are memory-safe (assuming no use of unsafe code)? They both achieved that distinction by adding a garbage collector, so you could generalize and say that nobody has learned about writing secure code since Lisp in 1958. Also, I'm pretty sure that Oberon was quite a bit earlier than that.
  - pcwalton 11y ago
    To be fair, the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure", which at least Ada does (Storage_Error).
    - viraptor 11y ago
      Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue. I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
      - steveklabnik 11y ago
        Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions. Rust's standard library aborts on OOM.
        viraptor 11y ago
        That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.
  - pjmlp 11y ago
    Yes, but the other ones already prevented: - implicit type conversions errors - memory allocations with incorrect size - implicit decay of arrays into pointers - lack of bounds checking for arrays - null terminated strings with missing null character - invalid pointers passed as argument for out parameters - implicit conversion of integers into invalid enumeration values
    - nwmcsween 11y ago
      Almost all of these are solvable without the added abstraction, code size increase that most languages bring, see dependent types.
      - pjmlp 11y ago
        Dependent types are great, but I fear not for the average programmer on the street, at least not on the current languages that make use of it.
striking 11y ago
They might downvote you, but I think your preemption of the flame war is a noble thing.
- tosseraccount 11y ago
  Looks like they showed up.
  - striking 11y ago
    But they're isolated here at the bottom.
topspin 11y ago
Another day, another memory violation... the endless supply of ammo dispenses another box of shells for Rust. I don't know if Rust is the future, but I am certain the dangling pointers, use after frees, buffer overflows, double frees, smashed stacks, ignored failures, uninitialized data and all the other horrors of contemporary C/C++ will one day be understood as intolerable.
- JoeAltmaier 11y ago
  These things can be reduced to nuisance level by discipline. The cost to obviating them by language design is not zero (code size; execution speed; random latencies) so its arguable, different languages, different purposes.
  - aschampion 11y ago
    > These things can be reduced to nuisance level by discipline. Obviously not. We've been doing this for decades and are still making the same mistakes with costly effects. Humans are as much a part of technological systems as the language or platform; continuing to ignore that even educated, disciplined, skilled developers are prone to certain classes of errors -- errors that could be obviated by other components of the system -- is hubris. It is much more feasible to create tools that exclude certain classes of error than to create less fallible developers. > (code size; execution speed; random latencies) Rust is not GC'ed, has no inherent reason to be slower than C (as the toolchain matures), and I doubt is more verbose than C code that provides the same safety.
    - JoeAltmaier 11y ago
      Speak for yourself. A power saw is dangerous; but I'm not going back thanks. And nothing to say about the performance cost of these infallible tools? They are not free.
      - kbenson 11y ago
        > A power saw is dangerous; but I'm not going back thanks. And now we have power saws that immediately stop when they encounter flesh. Obviously, disciplined users never had to worry about that system, otherwise we would have had a bunch of people missing fingers... like my wood shop teacher in high school. :/ > And nothing to say about the performance cost of these infallible tools? They are not free. People have brought this up a few times, but I've never gotten an explanation that makes sense. My understanding is that Rust does most of its protections in the compile stage, so while not free, they are a small up-front cost at the compile stage, plus an indeterminate cost at the development stage in possible more complex reasoning about the code, which then pays off over the lifetime of the application. While not free, that's definitely a trade-off that seems to make sense to me. Or are you talking about some other cost? Can you explain where I'm not understanding your point?

pjmlp 11y ago

Don't bother, they haven't learned about writing secure code since Extended Algol (1961), Mesa (early 70's), Modula-2 (1978), Cedar (early 80's), Ada (1983), Oberon (1991),... anyway.

tosseraccount 11y ago
17 years ago it was "Let's rewrite Unix in Perl" ... http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl I do wish them the best luck, though.
- jest3r1 11y ago
  Strange to go back in time.
cwzwarich 11y ago
Aren't Cedar and Oberon are the only languages in that list that are memory-safe (assuming no use of unsafe code)? They both achieved that distinction by adding a garbage collector, so you could generalize and say that nobody has learned about writing secure code since Lisp in 1958. Also, I'm pretty sure that Oberon was quite a bit earlier than that.
- pcwalton 11y ago
  To be fair, the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure", which at least Ada does (Storage_Error).
  - viraptor 11y ago
    Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue. I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
    - steveklabnik 11y ago
      Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions. Rust's standard library aborts on OOM.
      - viraptor 11y ago
        That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.
- pjmlp 11y ago
  Yes, but the other ones already prevented: - implicit type conversions errors - memory allocations with incorrect size - implicit decay of arrays into pointers - lack of bounds checking for arrays - null terminated strings with missing null character - invalid pointers passed as argument for out parameters - implicit conversion of integers into invalid enumeration values
  - nwmcsween 11y ago
    Almost all of these are solvable without the added abstraction, code size increase that most languages bring, see dependent types.
    - pjmlp 11y ago
      Dependent types are great, but I fear not for the average programmer on the street, at least not on the current languages that make use of it.

striking 11y ago

They might downvote you, but I think your preemption of the flame war is a noble thing.

tosseraccount 11y ago
Looks like they showed up.
- striking 11y ago
  But they're isolated here at the bottom.

topspin 11y ago

Another day, another memory violation... the endless supply of ammo dispenses another box of shells for Rust. I don't know if Rust is the future, but I am certain the dangling pointers, use after frees, buffer overflows, double frees, smashed stacks, ignored failures, uninitialized data and all the other horrors of contemporary C/C++ will one day be understood as intolerable.

JoeAltmaier 11y ago
These things can be reduced to nuisance level by discipline. The cost to obviating them by language design is not zero (code size; execution speed; random latencies) so its arguable, different languages, different purposes.
- aschampion 11y ago
  > These things can be reduced to nuisance level by discipline. Obviously not. We've been doing this for decades and are still making the same mistakes with costly effects. Humans are as much a part of technological systems as the language or platform; continuing to ignore that even educated, disciplined, skilled developers are prone to certain classes of errors -- errors that could be obviated by other components of the system -- is hubris. It is much more feasible to create tools that exclude certain classes of error than to create less fallible developers. > (code size; execution speed; random latencies) Rust is not GC'ed, has no inherent reason to be slower than C (as the toolchain matures), and I doubt is more verbose than C code that provides the same safety.
  - JoeAltmaier 11y ago
    Speak for yourself. A power saw is dangerous; but I'm not going back thanks. And nothing to say about the performance cost of these infallible tools? They are not free.
    - kbenson 11y ago
      > A power saw is dangerous; but I'm not going back thanks. And now we have power saws that immediately stop when they encounter flesh. Obviously, disciplined users never had to worry about that system, otherwise we would have had a bunch of people missing fingers... like my wood shop teacher in high school. :/ > And nothing to say about the performance cost of these infallible tools? They are not free. People have brought this up a few times, but I've never gotten an explanation that makes sense. My understanding is that Rust does most of its protections in the compile stage, so while not free, they are a small up-front cost at the compile stage, plus an indeterminate cost at the development stage in possible more complex reasoning about the code, which then pays off over the lifetime of the application. While not free, that's definitely a trade-off that seems to make sense to me. Or are you talking about some other cost? Can you explain where I'm not understanding your point?