6 ms·

Some of us are mentally scarred from decades of dealing with weak type systems, undefined behavior, and general inability to be sure of what's going on in garga

by roca 6y ago

Some of us are mentally scarred from decades of dealing with weak type systems, undefined behavior, and general inability to be sure of what's going on in gargantuan C++ codebases. Rust was more or less specifically designed to appeal to people like us. Throw a rope to a drowning person and they'll grab onto it hard.

otabdeveloper4 6y ago
Rust won't make legacy code and legacy coders go away. In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow. So Rust is not a solution.
- nicoburns 6y ago
  > In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow But it will make those codebases a lot easier to deal with because the Rust compiler enforces correctness in a myriad of ways that other languages don't. I would much, much rather deal with a legacy Rust codebase than a legacy C++ one.
  - otabdeveloper4 6y ago
    This isn't true. Or, rather, there are also a myriad of ways that C++ enforces correctness that Rust doesn't. Legacy codebases are smelly not because of a lack of tools for enforcing correctness. They're smelly because a) programming is hard, and b) a boatload of things are more important than correctness, in the real world. > I would much, much rather deal with a legacy Rust codebase than a legacy C++ Obviously, because right now legacy Rust codebases are only 5 years old, while legacy C++ codebases are 30+ years old. But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today.
    - nicoburns 6y ago
      > there are also a myriad of ways that C++ enforces correctness that Rust doesn't. There are? Like what? > But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today. I don't really believe this. There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. And Rust is stricter than Java.
      - otabdeveloper4 6y ago
        > There are? Like what? Exceptions, for example. > There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. That's because Java doesn't attempt to solve difficult problems.
        roca 6y ago
        Exceptions are terrible for correctness. They introduce hidden control flow paths that developers forget about and fail to handle correctly. (Also they break the "pay for what you use" principle, so C++ is split into two ecosystems, one which uses exceptions and one which doesn't.) Exceptions are better than magical return values to indicate errors, that's true, but Rust Results achieve the same thing without the downsides of exceptions. > That's because Java doesn't attempt to solve difficult problems. Java isn't my favourite language, but that's just silly. GraalVM will do as a counterexample.
        otabdeveloper4 6y ago
        > Exceptions are terrible for correctness. Sometimes they are, and sometimes they are not. > They introduce hidden control flow paths that developers forget about and fail to handle correctly. The problem that exceptions solve involve control flow paths that aren't supposed to be handled. Exceptions are not for handling recoverable errors, they are for graceful aborts in a complex, layered and modular program. (E.g., any multi-threaded server, for example.)
- 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
- mlindner 6y ago
  It doesn't no, but if I advocate for the language enough and get it used enough, I can guarantee for the entire rest of my career I can maybe avoid ever having to write any more new projects in said languages. I can just avoid jobs where such languages are still used commonly.
  - otabdeveloper4 6y ago
    Wait ten more years and Rust will become one of these 'said languages'. (Maybe even faster; the Rust people make it their principle to never learn from others' mistakes. There is no way they won't repeat them.)
    - roca 6y ago
      You're just making stuff up. Most aspects of Rust's design are based on lessons learned from mistakes and good ideas in C++ and other languages. There was a conscious effort to avoid inventing more new things than necessary.

by roca 6y ago

otabdeveloper4 6y ago

Rust won't make legacy code and legacy coders go away. In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow. So Rust is not a solution.

nicoburns 6y ago
> In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow But it will make those codebases a lot easier to deal with because the Rust compiler enforces correctness in a myriad of ways that other languages don't. I would much, much rather deal with a legacy Rust codebase than a legacy C++ one.
- otabdeveloper4 6y ago
  This isn't true. Or, rather, there are also a myriad of ways that C++ enforces correctness that Rust doesn't. Legacy codebases are smelly not because of a lack of tools for enforcing correctness. They're smelly because a) programming is hard, and b) a boatload of things are more important than correctness, in the real world. > I would much, much rather deal with a legacy Rust codebase than a legacy C++ Obviously, because right now legacy Rust codebases are only 5 years old, while legacy C++ codebases are 30+ years old. But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today.
  - nicoburns 6y ago
    > there are also a myriad of ways that C++ enforces correctness that Rust doesn't. There are? Like what? > But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today. I don't really believe this. There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. And Rust is stricter than Java.
    - otabdeveloper4 6y ago
      > There are? Like what? Exceptions, for example. > There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. That's because Java doesn't attempt to solve difficult problems.
      - roca 6y ago
        Exceptions are terrible for correctness. They introduce hidden control flow paths that developers forget about and fail to handle correctly. (Also they break the "pay for what you use" principle, so C++ is split into two ecosystems, one which uses exceptions and one which doesn't.) Exceptions are better than magical return values to indicate errors, that's true, but Rust Results achieve the same thing without the downsides of exceptions. > That's because Java doesn't attempt to solve difficult problems. Java isn't my favourite language, but that's just silly. GraalVM will do as a counterexample.
        otabdeveloper4 6y ago
        > Exceptions are terrible for correctness. Sometimes they are, and sometimes they are not. > They introduce hidden control flow paths that developers forget about and fail to handle correctly. The problem that exceptions solve involve control flow paths that aren't supposed to be handled. Exceptions are not for handling recoverable errors, they are for graceful aborts in a complex, layered and modular program. (E.g., any multi-threaded server, for example.)
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
mlindner 6y ago
It doesn't no, but if I advocate for the language enough and get it used enough, I can guarantee for the entire rest of my career I can maybe avoid ever having to write any more new projects in said languages. I can just avoid jobs where such languages are still used commonly.
- otabdeveloper4 6y ago
  Wait ten more years and Rust will become one of these 'said languages'. (Maybe even faster; the Rust people make it their principle to never learn from others' mistakes. There is no way they won't repeat them.)
  - roca 6y ago
    You're just making stuff up. Most aspects of Rust's design are based on lessons learned from mistakes and good ideas in C++ and other languages. There was a conscious effort to avoid inventing more new things than necessary.