5 ms·

I think the key thing people worry about with regard to "churn" is "OMG, do I have to update my code again?". Explicitly calling out that this release doesn't r

I think the key thing people worry about with regard to "churn" is "OMG, do I have to update my code again?". Explicitly calling out that this release doesn't really have any changes like that is good. I also think that's why the ecosystem change is in fact a big deal. People seem to feel pressured to keep up. Meanwhile I'm still not really sure what the consensus is, if any, on which error handling library we're supposed to use... Anyway, it might also be worth calling out somewhere that no, you don't have to follow the ecosystem and the hip idioms super closely if you just want to get some work done (and to the extent that's not true, making it so).

steveklabnik 7y ago
Thanks :) The current error handling consensus seems to be "anyhow for applications, either no crate or thiserror for libraries." Obviously this is not uniform, but the discussion + download counts point to this, imho.
- ucarion 7y ago
  To clarify for others: "anyhow" and "thiserror" are not placeholder names in that sentence. They refer to: https://github.com/dtolnay/anyhow https://github.com/dtolnay/anyhow https://github.com/dtolnay/thiserror https://github.com/dtolnay/thiserror
ChrisSD 7y ago
Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine. The consensus with error handling is that the limitations of std error trait have now been sufficiently fixed so as to be usable without anything more. But you can use a crate (like `thiserror`) to reduce boilerplate if you really want to.
- est31 7y ago
  > Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine. You have to update your dependencies though because every now and then, changes lead to breaking builds. I have a codebase from 2015, last touched in 2016, and many dependencies failed to compile, some because of changes in the language (those changes are only done to fix bugs but they still cause churn to users), others because the openssl wrapper doesn't support newer natively installed versions of openssl. It took me roughly an hour to fix all the issues and it's only a few hundred lines. Admittedly this is much much less effort than staying up with whatever the currently hyped error handling library is. And C++ projects often need effort to work on newer compilers as well because they invoke UB and the optimizer changed and led to segfaults. Seen it with my own eyes.
  - ChrisSD 7y ago
    Tbh I found OpenSSL to be its own world of pain. And that was from using it in C. ;)
  - dathinab 7y ago
    Most (all?) of this "dang we need to brake something because we made some stupid design mistake wrt. soundness" kind of braking changes should be done by now I think. So I think that when in 2024 someone build a code base from 2020 this shouldn't be a problem. Also sadly currently rust has not yet completely escaped from the C/C++ UB optimization hell ;-). There are some bugs caused by the interaction of Rust and LLVM UB optimizations. Like there was a problem with some float casts being UB (but should not have been). But we are getting there.
    - tux3 7y ago
      >Like there was a problem with some float casts being UB (but should not have been). And one of those is just about to get fixed, it looks like =] https://github.com/rust-lang/rust/pull/71269 https://github.com/rust-lang/rust/pull/71269
      - est31 7y ago
        I've already tested my lewton project with this change, and not the tiniest bit of a slowdown.
  - csdreamer7 7y ago
    For someone new to Rust. What past changes in the language broke the dependencies you used? Were they using the nightly branch?
    - est31 7y ago
      I ran into two issues, one in rustc-serialize broken by https://github.com/rust-lang/rust/issues/35203 https://github.com/rust-lang/rust/issues/35203 (fixable by cargo update -p rustc-serialize) and one in url broken by the move to NLL on the 2015 edition. The second is an important bugfix in the language, but it still broke my build :). Not sure how I fixed it but it's now fixed as well. Additional changes were required due to openssl. My own code has compiled just fine except for a ton of warnings (most about try! -> ? change) and the needed API updates of dependencies (2 changed lines). Most of the effort I spent on actually updating as little as possible. If you update everything you fix all issues resolvable by updates but you also have to adjust to every API change :).
- nerdponx 7y ago
  Also isn't the point of tools like Rustup is that you don't need to make sure your code is constantly up-to-date with respect to the compiler? Like you can keep using rustc 1.0 on code written for Rust 1.0, right?
nazka 7y ago
Maybe we need another number like 1.42.2? I have no idea if this can be relevant for languages.
- estebank 7y ago
  We already have minor releases, but they are exclusively for critical bugfixes. Everything else either rides the train (up to 12 weeks) or gets backported to beta (up to 6 weeks before hitting stable).

steveklabnik 7y ago

Thanks :) The current error handling consensus seems to be "anyhow for applications, either no crate or thiserror for libraries." Obviously this is not uniform, but the discussion + download counts point to this, imho.

ucarion 7y ago
To clarify for others: "anyhow" and "thiserror" are not placeholder names in that sentence. They refer to: https://github.com/dtolnay/anyhow https://github.com/dtolnay/anyhow https://github.com/dtolnay/thiserror https://github.com/dtolnay/thiserror

ChrisSD 7y ago

Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine. The consensus with error handling is that the limitations of std error trait have now been sufficiently fixed so as to be usable without anything more. But you can use a crate (like `thiserror`) to reduce boilerplate if you really want to.

est31 7y ago
> Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine. You have to update your dependencies though because every now and then, changes lead to breaking builds. I have a codebase from 2015, last touched in 2016, and many dependencies failed to compile, some because of changes in the language (those changes are only done to fix bugs but they still cause churn to users), others because the openssl wrapper doesn't support newer natively installed versions of openssl. It took me roughly an hour to fix all the issues and it's only a few hundred lines. Admittedly this is much much less effort than staying up with whatever the currently hyped error handling library is. And C++ projects often need effort to work on newer compilers as well because they invoke UB and the optimizer changed and led to segfaults. Seen it with my own eyes.
- ChrisSD 7y ago
  Tbh I found OpenSSL to be its own world of pain. And that was from using it in C. ;)
- dathinab 7y ago
  Most (all?) of this "dang we need to brake something because we made some stupid design mistake wrt. soundness" kind of braking changes should be done by now I think. So I think that when in 2024 someone build a code base from 2020 this shouldn't be a problem. Also sadly currently rust has not yet completely escaped from the C/C++ UB optimization hell ;-). There are some bugs caused by the interaction of Rust and LLVM UB optimizations. Like there was a problem with some float casts being UB (but should not have been). But we are getting there.
  - tux3 7y ago
    >Like there was a problem with some float casts being UB (but should not have been). And one of those is just about to get fixed, it looks like =] https://github.com/rust-lang/rust/pull/71269 https://github.com/rust-lang/rust/pull/71269
    - est31 7y ago
      I've already tested my lewton project with this change, and not the tiniest bit of a slowdown.
- csdreamer7 7y ago
  For someone new to Rust. What past changes in the language broke the dependencies you used? Were they using the nightly branch?
  - est31 7y ago
    I ran into two issues, one in rustc-serialize broken by https://github.com/rust-lang/rust/issues/35203 https://github.com/rust-lang/rust/issues/35203 (fixable by cargo update -p rustc-serialize) and one in url broken by the move to NLL on the 2015 edition. The second is an important bugfix in the language, but it still broke my build :). Not sure how I fixed it but it's now fixed as well. Additional changes were required due to openssl. My own code has compiled just fine except for a ton of warnings (most about try! -> ? change) and the needed API updates of dependencies (2 changed lines). Most of the effort I spent on actually updating as little as possible. If you update everything you fix all issues resolvable by updates but you also have to adjust to every API change :).
nerdponx 7y ago
Also isn't the point of tools like Rustup is that you don't need to make sure your code is constantly up-to-date with respect to the compiler? Like you can keep using rustc 1.0 on code written for Rust 1.0, right?

nazka 7y ago

Maybe we need another number like 1.42.2? I have no idea if this can be relevant for languages.

estebank 7y ago
We already have minor releases, but they are exclusively for critical bugfixes. Everything else either rides the train (up to 12 weeks) or gets backported to beta (up to 6 weeks before hitting stable).