4 ms·

Fortunately I am mostly able to avoid working on legacy C++ code these days (rr being the exception, and it's only 70K lines). Rust code accumulates some cruft

by roca 6y ago

Fortunately I am mostly able to avoid working on legacy C++ code these days (rr being the exception, and it's only 70K lines). Rust code accumulates some cruft over time, but Rust's type system and safety guarantees put a floor on how crappy the code can be. The first Rust code I ever wrote is still part of my project five years later; it's less than perfect, but it's free of undefined behavior now just as it was then. The data structure parsers I wrote four years ago look a bit ugly to me now, but are free of exploitable security bugs, and always were. Etc.

otabdeveloper4 6y ago
> undefined behavior What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.) If you refuse to define anything then you automatically make the "undefinedness" problem go away. (But not the pain it causes.) > Rust's type system and safety guarantees put a floor on how crappy the code can be No. The floor on crappiness is defined by the problem domain. Powerful features allow for powerful takes on crappiness. Unless you want Rust to stay a teaching language forever, you must necessarily introduce abusable features. (See Python for a real-time slow-motion elaboration of this train wreck if you don't believe me.)
- roca 6y ago
  > What does that even mean in the absence of a formal standard and competing compiler implementations? It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says). They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.) > Powerful features allow for powerful takes on crappiness. I don't know what this means. > Unless you want Rust to stay a teaching language forever A lot of companies big and small are using Rust in production so this is not a compelling premise.
  - otabdeveloper4 6y ago
    "Undefined behavior" in a C++ context is a legalese feature of the ISO standard. The standard defines, very precisely, the behavior of a compliant C++ compiler. In places where behavior cannot be specified (for logical or practical reasons), the behavior is marked as "undefined". In absence of a standard effectively every language construct is 'undefined behavior'. Again, look at Python for a vivid example of this. (We were discussing just this is a neighboring thread: https://news.ycombinator.com/item?id=26826158 https://news.ycombinator.com/item?id=26826158) I have zero reason to believe that Rust won't meet Python's fate. The Rust people don't have a standard and don't understand why they need one; in fact, their lack of standards is somehow touted as a benefit. Apparently, people think that if there is no standard for "defined" and "undefined" behavior that everything is "defined" by default. (They're absolutely wrong, of course; it's actually the opposite.)
    - wmanley 6y ago
      What you seem to be describing is "unspecified behaviour" or "implementation defined behaviour". If your program contains undefined behaviour the compiler makes no guarantees about how your program will behave. For more see: https://blog.regehr.org/archives/213 https://blog.regehr.org/archives/213 and https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html https://raphlinus.github.io/programming/rust/2018/08/17/unde... .
      - nwmcsween 6y ago
        If there is one implementation as the definition then by default all behaviour is defined by the implementation, and hence parent is correct.
        wmanley 5y ago
        No. If we accept your argument then this would be correct: > In absence of a standard effectively every language construct is 'implementation defined behaviour'. But the parent said: > In absence of a standard effectively every language construct is 'undefined behavior'. Undefined behaviour != implementation defined behaviour. Both of these things exist in C and are separate. You can rely on implementation defined behaviour giving some consistent result on a given, compiler and hardware. You cannot rely on the behaviour of your program if you hit undefined behaviour.
- ssokolow 6y ago
  > What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.) Undefined behaviour is stuff that you compiler's optimizers have been promised can never occur, so they are allowed to transform your code based on that assumption. Here's a post I made on Reddit in 2019 with a list of resources on what undefined behaviour is: https://www.reddit.com/r/rust/comments/dpxswt/rust_2020_lets_embrace_the_eternal_september/f5zwxuv/ https://www.reddit.com/r/rust/comments/dpxswt/rust_2020_lets... ...and here's the link to an example of what invoking undefined behaviour can do in C++: https://gcc.godbolt.org/z/0ubnbS https://gcc.godbolt.org/z/0ubnbS ...and here's an explanation of why it does what it does: https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior... (TL;DR: It injects a call to EraseAll because calling Do while it's still null is undefined behaviour, and Do is a static, so the optimizer determines that the only possible answer within the rules it was given is that code outside that compilation unit will have called NeverCalled to set Do = EraseAll before invoking main().)

by roca 6y ago

otabdeveloper4 6y ago

> undefined behavior What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.) If you refuse to define anything then you automatically make the "undefinedness" problem go away. (But not the pain it causes.) > Rust's type system and safety guarantees put a floor on how crappy the code can be No. The floor on crappiness is defined by the problem domain. Powerful features allow for powerful takes on crappiness. Unless you want Rust to stay a teaching language forever, you must necessarily introduce abusable features. (See Python for a real-time slow-motion elaboration of this train wreck if you don't believe me.)

roca 6y ago
> What does that even mean in the absence of a formal standard and competing compiler implementations? It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says). They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.) > Powerful features allow for powerful takes on crappiness. I don't know what this means. > Unless you want Rust to stay a teaching language forever A lot of companies big and small are using Rust in production so this is not a compelling premise.
- otabdeveloper4 6y ago
  "Undefined behavior" in a C++ context is a legalese feature of the ISO standard. The standard defines, very precisely, the behavior of a compliant C++ compiler. In places where behavior cannot be specified (for logical or practical reasons), the behavior is marked as "undefined". In absence of a standard effectively every language construct is 'undefined behavior'. Again, look at Python for a vivid example of this. (We were discussing just this is a neighboring thread: https://news.ycombinator.com/item?id=26826158 https://news.ycombinator.com/item?id=26826158) I have zero reason to believe that Rust won't meet Python's fate. The Rust people don't have a standard and don't understand why they need one; in fact, their lack of standards is somehow touted as a benefit. Apparently, people think that if there is no standard for "defined" and "undefined" behavior that everything is "defined" by default. (They're absolutely wrong, of course; it's actually the opposite.)
  - wmanley 6y ago
    What you seem to be describing is "unspecified behaviour" or "implementation defined behaviour". If your program contains undefined behaviour the compiler makes no guarantees about how your program will behave. For more see: https://blog.regehr.org/archives/213 https://blog.regehr.org/archives/213 and https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html https://raphlinus.github.io/programming/rust/2018/08/17/unde... .
    - nwmcsween 6y ago
      If there is one implementation as the definition then by default all behaviour is defined by the implementation, and hence parent is correct.
      - wmanley 5y ago
        No. If we accept your argument then this would be correct: > In absence of a standard effectively every language construct is 'implementation defined behaviour'. But the parent said: > In absence of a standard effectively every language construct is 'undefined behavior'. Undefined behaviour != implementation defined behaviour. Both of these things exist in C and are separate. You can rely on implementation defined behaviour giving some consistent result on a given, compiler and hardware. You cannot rely on the behaviour of your program if you hit undefined behaviour.
ssokolow 6y ago
> What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.) Undefined behaviour is stuff that you compiler's optimizers have been promised can never occur, so they are allowed to transform your code based on that assumption. Here's a post I made on Reddit in 2019 with a list of resources on what undefined behaviour is: https://www.reddit.com/r/rust/comments/dpxswt/rust_2020_lets_embrace_the_eternal_september/f5zwxuv/ https://www.reddit.com/r/rust/comments/dpxswt/rust_2020_lets... ...and here's the link to an example of what invoking undefined behaviour can do in C++: https://gcc.godbolt.org/z/0ubnbS https://gcc.godbolt.org/z/0ubnbS ...and here's an explanation of why it does what it does: https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior... (TL;DR: It injects a call to EraseAll because calling Do while it's still null is undefined behaviour, and Do is a static, so the optimizer determines that the only possible answer within the rules it was given is that code outside that compilation unit will have called NeverCalled to set Do = EraseAll before invoking main().)