8 ms·

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 err

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 :).
  - edflsafoiewq 7y ago
    e: this is wrong Dependencies can set lints to deny. When lints change, they might not compile anymore. (I think denying lints is a bad idea, just like -Werror)
    - steveklabnik 7y ago
      Doesn't cargo's behavior of capping lints prevent this?
      - edflsafoiewq 7y ago
        Yes, you're right. I thought I had seen this in dependencies, but I must have been compiling something directly.
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?

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 :).
- edflsafoiewq 7y ago
  e: this is wrong Dependencies can set lints to deny. When lints change, they might not compile anymore. (I think denying lints is a bad idea, just like -Werror)
  - steveklabnik 7y ago
    Doesn't cargo's behavior of capping lints prevent this?
    - edflsafoiewq 7y ago
      Yes, you're right. I thought I had seen this in dependencies, but I must have been compiling something directly.

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?