6 ms·

I don't. I use rust from debian repos. In Debian 11 (bullseye), a distro which has not even been released yet, it has Rust 1.48 from 2020-11-19. This already is

I don't. I use rust from debian repos. In Debian 11 (bullseye), a distro which has not even been released yet, it has Rust 1.48 from 2020-11-19. This already is out of date and was unable to compile the two 1.50 targeting applications I wanted to try out. And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any.

csomar 6y ago
This might be a case of a dependency that doesn't respect SemVer? Did you post this incidence? Edit: Just re-read your comment. Maybe ping the guys in Debian to update their repos?
foota 6y ago
Typescript and node?
jacobolus 6y ago
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.
the_mitsuhiko 6y ago
I maintain a project which has _a bunch_ of dependencies and tests im CI that it can compile on 1.41. That’s a lot of dependencies: https://crates.io/crates/insta/1.7.1/dependencies https://crates.io/crates/insta/1.7.1/dependencies
deleted 6y ago
[deleted]
da_big_ghey 6y ago
i am not rust user, but many language are use its own pacage managing. making pacage first through language then through distro are two layer of review it must pass, so are always slow. i am not hearing persons complain on ruby, python, javascript, go, r, perl, ... use own pacage manage. rust are not a different here. in future maybe it stabalize and we are then having fewer update for to manage.
howinteresting 6y ago
Plenty of C++ code can't use modern C++ features because of Linux distributions holding everyone back. I think this is a bad thing and don't want these concerns to seep into Rust as well (outside of "fundamental" libraries.) Safety-critical systems may need these guarantees, but I object to them externalizing the costs they need to bear on the whole community. Almost everyone should be on up-to-date compilers, assuming the compilers promise that they won't break old code. The more we move towards that world the better.
ogoffart 6y ago
Yeah, this is a problem that the distribution packaged rust compiler is quickly out of date compared to what most of the ecosystem expect. However there is hope for a better future: https://github.com/rust-lang/rust/issues/65262 https://github.com/rust-lang/rust/issues/65262 will allow crates to specify a minimum supported rust version (MSRV), this way, we can imagine cargo resolving algorithm taking the installed rust version into account when picking the version of a crate to download so it would pick the last version of the crate that still compile on your system. Another thing is the Sealed Rust / Ferrocene initiative [https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/]. The idea is to have a version of rust supported for a long time, and it is likely that many core crates from the ecosystem will decide to keep compatibility with that LTS version.
- ogoffart 6y ago
  Relying to myself to mention another thing: https://github.com/rust-lang/rust/issues/64796 https://github.com/rust-lang/rust/issues/64796 is adding support for a #[cfg(version(x.y))] tag that will allow crates to more easily provide additional feature when using newer compiler, while still being compatible with older rust versions.
hctaw 6y ago
It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. The recommended way to manage your rust installation is rustup. It makes it trivial to set up and manage tool chains, globally or otherwise. > what other compiler is only usable if you install from some website instead of your repos? What compilers' recommended installation is some 3rd party package manager that lags behind the latest stable release by months? Rustup is a useful tool, it's dumb to ignore it.
- disgruntledphd2 6y ago
  > It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. And this is a terrible development that we should all try to resist, as it leads to a combinatoral explosion of dependencies and problems, as soon as you introduce another language. So then we end up using docker to encapsulate things because they are hard to manage on one box. It just seems crazy, but I don't really have much of a solution, tbh. Perhaps we could just install the build tool (in this case rustup) for supported languages and stop trying.
  - hctaw 6y ago
    I don't think it's terrible. Modern package management just works on a different assumption - the dependencies and their artifacts are required at build time, and for libraries they cannot assume the version required by the software exists outside the build environment or in deployment. If all of software respected those assumptions then we wouldn't need containerization nearly to the degree we have it today.
    - disgruntledphd2 6y ago
      It's all fine until you start needing multiple language package managers, each with their own C/C++ dependencies, and then it gets a lot trickier. I mean, I know how to handle it, but it's pretty depressing that I need to do it, when in the past one could rely on relatively recent versions of everything existing with a system package manager. I always need C/C++/Java dependencies in DS, so maybe I just feel the pain points more.
jen20 6y ago
I see this complaint a lot. The answer is not for people to not use modern features of tools with frankly very reasonable cadence, but instead for distributions to adapt to a world where things are not distributed on CDs any more.
akiselev 6y ago
The problem is that you chose a Linux distro with an explicit stability guarantee and a slower release cadence than Rust. If you had chosen a rolling distro like Arch, you wouldn't have to use Rustup.
sophacles 6y ago
> And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any. Lets see... i had this problem with python all the time, the system python version was notoriously old and out of date on macos, redhat, debian, etc. This is how pip and pyenv and a dozen other tools were born. Similar things with node. Or when the distro gcc has a bug that your code hits. Go has this problem too - e.g. the pain around moving from nothing -> dep -> modules was real (if not widely publicized). The language provided version/package manager solves a very real problem. That problem is a mismatch in what a system package should be vs what a development package should be. In some sense containers, nix/guix stye package management, and language specific dependency managers are different approaches to solving the problem: what my computer runs for daily use should be relatively stable and generally I won't need the latest and greatest package features in software I use - upstream developers have generaly dealt with various library deficiencies bugs in their dependencies. In software I develop though, I regularly hit api bugs and sure would like to just use version+1 instead of spending time developing around it. Particularly when the output of my development is a binary that is running in a container on some server.

csomar 6y ago

This might be a case of a dependency that doesn't respect SemVer? Did you post this incidence? Edit: Just re-read your comment. Maybe ping the guys in Debian to update their repos?

foota 6y ago

Typescript and node?

jacobolus 6y ago

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.

the_mitsuhiko 6y ago

I maintain a project which has _a bunch_ of dependencies and tests im CI that it can compile on 1.41. That’s a lot of dependencies: https://crates.io/crates/insta/1.7.1/dependencies https://crates.io/crates/insta/1.7.1/dependencies

deleted 6y ago

[deleted]

da_big_ghey 6y ago

i am not rust user, but many language are use its own pacage managing. making pacage first through language then through distro are two layer of review it must pass, so are always slow. i am not hearing persons complain on ruby, python, javascript, go, r, perl, ... use own pacage manage. rust are not a different here. in future maybe it stabalize and we are then having fewer update for to manage.

howinteresting 6y ago

Plenty of C++ code can't use modern C++ features because of Linux distributions holding everyone back. I think this is a bad thing and don't want these concerns to seep into Rust as well (outside of "fundamental" libraries.) Safety-critical systems may need these guarantees, but I object to them externalizing the costs they need to bear on the whole community. Almost everyone should be on up-to-date compilers, assuming the compilers promise that they won't break old code. The more we move towards that world the better.

ogoffart 6y ago

Yeah, this is a problem that the distribution packaged rust compiler is quickly out of date compared to what most of the ecosystem expect. However there is hope for a better future: https://github.com/rust-lang/rust/issues/65262 https://github.com/rust-lang/rust/issues/65262 will allow crates to specify a minimum supported rust version (MSRV), this way, we can imagine cargo resolving algorithm taking the installed rust version into account when picking the version of a crate to download so it would pick the last version of the crate that still compile on your system. Another thing is the Sealed Rust / Ferrocene initiative [https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/]. The idea is to have a version of rust supported for a long time, and it is likely that many core crates from the ecosystem will decide to keep compatibility with that LTS version.

ogoffart 6y ago
Relying to myself to mention another thing: https://github.com/rust-lang/rust/issues/64796 https://github.com/rust-lang/rust/issues/64796 is adding support for a #[cfg(version(x.y))] tag that will allow crates to more easily provide additional feature when using newer compiler, while still being compatible with older rust versions.

hctaw 6y ago

It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. The recommended way to manage your rust installation is rustup. It makes it trivial to set up and manage tool chains, globally or otherwise. > what other compiler is only usable if you install from some website instead of your repos? What compilers' recommended installation is some 3rd party package manager that lags behind the latest stable release by months? Rustup is a useful tool, it's dumb to ignore it.

disgruntledphd2 6y ago
> It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. And this is a terrible development that we should all try to resist, as it leads to a combinatoral explosion of dependencies and problems, as soon as you introduce another language. So then we end up using docker to encapsulate things because they are hard to manage on one box. It just seems crazy, but I don't really have much of a solution, tbh. Perhaps we could just install the build tool (in this case rustup) for supported languages and stop trying.
- hctaw 6y ago
  I don't think it's terrible. Modern package management just works on a different assumption - the dependencies and their artifacts are required at build time, and for libraries they cannot assume the version required by the software exists outside the build environment or in deployment. If all of software respected those assumptions then we wouldn't need containerization nearly to the degree we have it today.
  - disgruntledphd2 6y ago
    It's all fine until you start needing multiple language package managers, each with their own C/C++ dependencies, and then it gets a lot trickier. I mean, I know how to handle it, but it's pretty depressing that I need to do it, when in the past one could rely on relatively recent versions of everything existing with a system package manager. I always need C/C++/Java dependencies in DS, so maybe I just feel the pain points more.

jen20 6y ago

I see this complaint a lot. The answer is not for people to not use modern features of tools with frankly very reasonable cadence, but instead for distributions to adapt to a world where things are not distributed on CDs any more.

akiselev 6y ago

The problem is that you chose a Linux distro with an explicit stability guarantee and a slower release cadence than Rust. If you had chosen a rolling distro like Arch, you wouldn't have to use Rustup.

sophacles 6y ago

> And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any. Lets see... i had this problem with python all the time, the system python version was notoriously old and out of date on macos, redhat, debian, etc. This is how pip and pyenv and a dozen other tools were born. Similar things with node. Or when the distro gcc has a bug that your code hits. Go has this problem too - e.g. the pain around moving from nothing -> dep -> modules was real (if not widely publicized). The language provided version/package manager solves a very real problem. That problem is a mismatch in what a system package should be vs what a development package should be. In some sense containers, nix/guix stye package management, and language specific dependency managers are different approaches to solving the problem: what my computer runs for daily use should be relatively stable and generally I won't need the latest and greatest package features in software I use - upstream developers have generaly dealt with various library deficiencies bugs in their dependencies. In software I develop though, I regularly hit api bugs and sure would like to just use version+1 instead of spending time developing around it. Particularly when the output of my development is a binary that is running in a container on some server.