6 ms·

So your complaint is that Rust library authors are too excited to use new stable features as soon as they are available, and your preference would be for them t

So your complaint is that Rust library authors are too excited to use new stable features as soon as they are available, and your preference would be for them to wait e.g. a year before adopting new language features, so that their code keeps working with old compiler versions? Hard to see this as a problem with the language per se. What is the language supposed to do, ship working features but ask people politely not to use them? Not ship new features even if they solve acute problems? As a library consumer, if you want you can just stick to >6 month old versions of all the libraries you depend on, and they should work fine with your 6 month old compiler version.

rhn_mk1 6y ago
It's not a problem with the language directly, but with its culture. People being excited to use new feature is a nice thing for them, but the trade off is that the consumers of their work may suffer.
- mijamo 6y ago
  It is actually a problem with the language as well because it is still missing a lot of important things, so releases actually change your productivity and you use the shiny new features because they solve real pains. And this is far from over because there's still a lot of pain in rust development and a lot in the work to fix it. The same could have been said about JS/typescript where so many things were annoying that people rushed to use the new features. This is getting a bit calmer now because the new annual features are less life changing. Eventually maybe in 5 years Rust will have it's major pains solved and things slow down a bit. Maybe then the release schedule will actually change as well? Who knows
  - nindalf 6y ago
    What are the features you expect Rust to gain between now and 5 years from now? As for major language features I remember async await from a year ago, const generics recently and that’s it. If you can remember more features that fundamentally changed how we write code, please let us know. I don’t think many features are expected in the near future apart from maybe generic associated types. But not any time soon either. I think you might be seeing releases every six weeks and assume that each of these bring massive changes. They don’t. Each is a small iterative improvement. Take a look at the Rust release notes if you like.
    - tene 6y ago
      Non-Lexical Lifetimes were a pretty big quality-of-life improvement. The question mark operator was also quite nice.
      - steveklabnik 6y ago
        NLL landed in 1.31, in 2018, and ? landed in 1.13, in 2016. two and a half and five years ago :)
    - rhn_mk1 6y ago
      Generators is one. Custom allocators and anything else required to build bare-metal software. Compiling Rust itself, especially std::core. I hit that wall when trying to cross-compile using stable Rust that came with my distro.
superkuh 6y ago
Correct. It's the extremely rapid pace of development in the language combined with enthusiast devs using the latest and greatest that make it unsuitable for general use. Part of this stems from Rust almost requiring installing with rust-up instead of from repos. This encourages the bad behavior. Eventually the Rust dev community will grow enough to have non-language-specific-enthusiasts devs as a majority and it will slow down and begin to target actually stable releases. But as of now you have about 5 months functionality per "stable" release.
- darkwater 6y ago
  I understand your point and kind of agree but you should also keep in mind that Rust is a relatively young language. I would treat these as growing pains.
- rapsey 6y ago
  Strange how a language according to you is unsuitable for general use. Yet it is used by Google, Facebook, Apple, Amazon, Dropbox, Microsoft, Mozilla, Huawei, etc. You live by some principles. Most people don't care about the principles you seem to care very much about. Most just have problems that need solving and Rust is the best tool for solving them. If the tool works differently to how they are used to working, they adapt and get on with their lives.
  - hu3 6y ago
    This comparison doesn't make sense. Not everyone has Google or Facebook money and engineering. Just because they can doesn't mean you can. They solve Google problems. And they use Rust to solve specialized problems because at their scale it is worth squeezing every advantage. For mortals like you and me most problems should be faced with a completely different mindset.
    - rapsey 6y ago
      What does money have to do with using rustup?
deleted 6y ago
[deleted]
est31 6y ago
It's a bunch of problems. Firstly, you can't even say, reasonably, that you only want >6 month old versions of libraries, at least not with cargo. Yes, you can express such a wish for your direct dependencies, by using = versions in Cargo.toml, but the transitive dependencies, aka the dependencies of your dependencies and so on, those you can't control. Putting Cargo.lock into git solves some of your problems, but this doesn't help you when you are adding a library. Then, for any novel transitive dependency, Cargo just takes the highest version that works. The second problem is that even if 90% of your dependencies support older compilers, it doesn't matter, because the 10% that insist on newer compilers will still break. It can be a single dependency, and you usually have hundreds, with vastly different policies. There are solutions to this problem, like MSRV aware cargo. They just need someone to implement them (as well as someone to compute MSRV numbers).
- jacobolus 6y ago
  What proportion of programmers/projects are (a) so risk averse/untrusting that they are unwilling to update their compiler to the latest version, but (b) want to depend on the latest version of hundreds of miscellaneous libraries?
  - est31 6y ago
    Again, that's how the default development workflow with rust, which uses cargo, works. Including the cargo that's packaged by debian.
    - tene 6y ago
      I think you'll find that using an old Rust from Debian is not the default development workflow for most Rust users: https://blog.rust-lang.org/images/2020-12-rust-survey-2020/rust-versions.svg https://blog.rust-lang.org/images/2020-12-rust-survey-2020/r...
    - StavrosK 6y ago
      Hmm, what language lets you use new libraries with old compilers? The only ones I can think of are languages that have stopped being developed, because as soon one of your dependencies uses a new feature, you're done. I'm just not sure how what you're describing would work.

rhn_mk1 6y ago

It's not a problem with the language directly, but with its culture. People being excited to use new feature is a nice thing for them, but the trade off is that the consumers of their work may suffer.

mijamo 6y ago
It is actually a problem with the language as well because it is still missing a lot of important things, so releases actually change your productivity and you use the shiny new features because they solve real pains. And this is far from over because there's still a lot of pain in rust development and a lot in the work to fix it. The same could have been said about JS/typescript where so many things were annoying that people rushed to use the new features. This is getting a bit calmer now because the new annual features are less life changing. Eventually maybe in 5 years Rust will have it's major pains solved and things slow down a bit. Maybe then the release schedule will actually change as well? Who knows
- nindalf 6y ago
  What are the features you expect Rust to gain between now and 5 years from now? As for major language features I remember async await from a year ago, const generics recently and that’s it. If you can remember more features that fundamentally changed how we write code, please let us know. I don’t think many features are expected in the near future apart from maybe generic associated types. But not any time soon either. I think you might be seeing releases every six weeks and assume that each of these bring massive changes. They don’t. Each is a small iterative improvement. Take a look at the Rust release notes if you like.
  - tene 6y ago
    Non-Lexical Lifetimes were a pretty big quality-of-life improvement. The question mark operator was also quite nice.
    - steveklabnik 6y ago
      NLL landed in 1.31, in 2018, and ? landed in 1.13, in 2016. two and a half and five years ago :)
  - rhn_mk1 6y ago
    Generators is one. Custom allocators and anything else required to build bare-metal software. Compiling Rust itself, especially std::core. I hit that wall when trying to cross-compile using stable Rust that came with my distro.

superkuh 6y ago

Correct. It's the extremely rapid pace of development in the language combined with enthusiast devs using the latest and greatest that make it unsuitable for general use. Part of this stems from Rust almost requiring installing with rust-up instead of from repos. This encourages the bad behavior. Eventually the Rust dev community will grow enough to have non-language-specific-enthusiasts devs as a majority and it will slow down and begin to target actually stable releases. But as of now you have about 5 months functionality per "stable" release.

darkwater 6y ago
I understand your point and kind of agree but you should also keep in mind that Rust is a relatively young language. I would treat these as growing pains.
rapsey 6y ago
Strange how a language according to you is unsuitable for general use. Yet it is used by Google, Facebook, Apple, Amazon, Dropbox, Microsoft, Mozilla, Huawei, etc. You live by some principles. Most people don't care about the principles you seem to care very much about. Most just have problems that need solving and Rust is the best tool for solving them. If the tool works differently to how they are used to working, they adapt and get on with their lives.
- hu3 6y ago
  This comparison doesn't make sense. Not everyone has Google or Facebook money and engineering. Just because they can doesn't mean you can. They solve Google problems. And they use Rust to solve specialized problems because at their scale it is worth squeezing every advantage. For mortals like you and me most problems should be faced with a completely different mindset.
  - rapsey 6y ago
    What does money have to do with using rustup?

deleted 6y ago

[deleted]

est31 6y ago

It's a bunch of problems. Firstly, you can't even say, reasonably, that you only want >6 month old versions of libraries, at least not with cargo. Yes, you can express such a wish for your direct dependencies, by using = versions in Cargo.toml, but the transitive dependencies, aka the dependencies of your dependencies and so on, those you can't control. Putting Cargo.lock into git solves some of your problems, but this doesn't help you when you are adding a library. Then, for any novel transitive dependency, Cargo just takes the highest version that works. The second problem is that even if 90% of your dependencies support older compilers, it doesn't matter, because the 10% that insist on newer compilers will still break. It can be a single dependency, and you usually have hundreds, with vastly different policies. There are solutions to this problem, like MSRV aware cargo. They just need someone to implement them (as well as someone to compute MSRV numbers).

jacobolus 6y ago
What proportion of programmers/projects are (a) so risk averse/untrusting that they are unwilling to update their compiler to the latest version, but (b) want to depend on the latest version of hundreds of miscellaneous libraries?
- est31 6y ago
  Again, that's how the default development workflow with rust, which uses cargo, works. Including the cargo that's packaged by debian.
  - tene 6y ago
    I think you'll find that using an old Rust from Debian is not the default development workflow for most Rust users: https://blog.rust-lang.org/images/2020-12-rust-survey-2020/rust-versions.svg https://blog.rust-lang.org/images/2020-12-rust-survey-2020/r...
  - StavrosK 6y ago
    Hmm, what language lets you use new libraries with old compilers? The only ones I can think of are languages that have stopped being developed, because as soon one of your dependencies uses a new feature, you're done. I'm just not sure how what you're describing would work.