7 ms·

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 on

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.)
        ssokolow 6y ago
        > 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.) For control flow paths that are considered irrecoverable (ie. "this can never happen" branches), Rust has panic!(), which defaults to unwinding the stack, calling Drop implementations (destructors) along the way. panic!() unwinding only kills the thread it occurs in and Rust's thread-related APIs are designed around preventing data that's been left in an inconsistent state from being observable in other threads without explicitly acknowledging that you're dealing with something like a mutex that's set its "poisoned" flag. For control flow paths that are considered recoverable, Result<T, E> is basically a way to get checked exceptions which work naturally with higher order functions and have a more concise "call the defined conversion to the specified error return type if necessary, and re-throw" syntax. If you implement the From/Into interface to define how to convert the error type you received into the error type you're returning, the ? operator will do an "unwrap the Ok value or convert and do an early return of the Err value" in a single character. A lot of people use the thiserror crate to define their custom error types, which has helpers to makeimplementing the From/Into interface trivial... possibly as trivial as annotating an enum variant with #[from], depending on what you want out of it. Also, this is from 2005 and chose a "considered harmful" title, but this article makes some good points: http://www.lighterra.com/papers/exceptionsharmful/ http://www.lighterra.com/papers/exceptionsharmful/
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.

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.)
        ssokolow 6y ago
        > 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.) For control flow paths that are considered irrecoverable (ie. "this can never happen" branches), Rust has panic!(), which defaults to unwinding the stack, calling Drop implementations (destructors) along the way. panic!() unwinding only kills the thread it occurs in and Rust's thread-related APIs are designed around preventing data that's been left in an inconsistent state from being observable in other threads without explicitly acknowledging that you're dealing with something like a mutex that's set its "poisoned" flag. For control flow paths that are considered recoverable, Result<T, E> is basically a way to get checked exceptions which work naturally with higher order functions and have a more concise "call the defined conversion to the specified error return type if necessary, and re-throw" syntax. If you implement the From/Into interface to define how to convert the error type you received into the error type you're returning, the ? operator will do an "unwrap the Ok value or convert and do an early return of the Err value" in a single character. A lot of people use the thiserror crate to define their custom error types, which has helpers to makeimplementing the From/Into interface trivial... possibly as trivial as annotating an enum variant with #[from], depending on what you want out of it. Also, this is from 2005 and chose a "considered harmful" title, but this article makes some good points: http://www.lighterra.com/papers/exceptionsharmful/ http://www.lighterra.com/papers/exceptionsharmful/

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.