5 ms·

Rust releases only last about 5 months before they're so out of date you can't compile something written $today. I suppose this is a perfect fit for Facebook th

Rust releases only last about 5 months before they're so out of date you can't compile something written $today. I suppose this is a perfect fit for Facebook though since they control their entire stack and rebuilding the world is a-ok. It's not so okay if you're trying to write something you expect other people to be able to compile and run.

dijit 6y ago
Stop using +nightly. Stable rust hasn't broken in my experience.
- superkuh 6y ago
  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.
        6y ago
  - 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.
- deleted 6y ago
  [deleted]
pizza234 6y ago
I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, builds fine as well.
- steveklabnik 6y ago
  I think your comment is good, but also, your comment and the parent comment highlight a situation that makes this discussion hard: you're both talking about two different things. You're talking about using a current compiler to build old code, aka, backwards compatibility. We put a lot of time and effort into this, because it's important, and we're not perfect, but we're pretty darn good at it, it seems. The parent is talking about using an older compiler to build newer code, aka, forwards compatibility. Basically no programming languages I'm aware of provides this today, but they release on a much slower schedule, which means that in practice, it is likely to happen less often. Because Rust ships so often, and because it's so easy to upgrade Rust, the community tends to adopt newer features faster than in other language ecosystems, meaning that forward compatibility becomes more of an issue if you do not want to update the compiler.
  - swsieber 6y ago
    To build on this, there are parts of the ecosystem that explicitly outline their Minimum Supported Rust Version. Sometimes it's short (e.g. last two stable releases), and sometimes it's longer (6+ most recent stable releases). What's not well expressed is that is that certain releases prompt a bunch of people to upgrade the newest libraries to require the latest stable release. And these releases are not easily visible or predictable from outside the community. This is driven by Rust releases that stabilize significant features; I'm talking about stuff like async, min const generics, impl trait, proc macro support. So support for older releases tends to wax and wane depending on how recently a big feature was stabilized. There is one other contributing factor - cargo tries to pick the most recent version of library (that's SemVer compliant), not the earliest one, and MSRV changes aren't at this point considered a breaking SemVer change (as far as I know)
  - returningfory2 6y ago
csomar 6y ago
That's really weird. So far Rust has been the most stable thing I have worked with. Working with Cargo was a pleasant experience knowing that I will compile any program and the compilation will go smoothly (vs. Python where I have multiple times figure out what went wrong).
otabdeveloper4 6y ago
Don't blaspheme against the FOTM gods. Today is the year of the Rust. Wait until next year when $language is the next shining beacon of not-having-to-deal-with-legacy and Rust itself goes to the dustheap where Cobol and Fortran and Python 3.6 now live.
- dave_sid 6y ago
  Rust was doomed to fail from the start.
  - yjftsjthsd-h 6y ago
    Why?
reificator 6y ago
I don't understand your concern. You're upset that new features are not backported to older compiler versions? If you have some reason to not update your compiler, then don't use those new features, and use dependency versions that also don't use those features. Go back a few releases if you need to. If you do need those features though... Then just upgrade your compiler? I'm not aware of any compilers/interpreters that work the way you want here. Maybe Python 2 for that painful decade of overlap...
mamcx 6y ago
I have done more than dozen of languages and consider Rust the best experience for both "get new shinny things" and "keep old quiet". But the Rust experience IS cargo. No (other) package managers. Rust is cargo centric. With it, you are free to pin to versions and keep things working for very long. BUT also if you are coming cold to any library is to be EXPECTED to be "new". This is a good thing: The community at large move forward in tandem as if it were a coordinated army! But that don't mean I can't work with older code, is that if you see a crate RIGTH NOW you see te forward momentum at large. If you wanna use something older you can pin to a back version. However, this also point to a fair problem: Is not easy to correlate to which version of Rust each crate(version) relate to.
- deleted 6y ago
  [deleted]
carlosdp 6y ago
That's just blatantly false. Rust takes extreme pains to be backwards compatible. When they wanted to make breaking changes to support some new language features, they literally spun up a separate compiler front-end behind a cargo.toml flag to make sure they didn't break any existing code. Compiler changes are tested against a bunch of libraries in the crates.io repository to ensure nothing breaks. It's just exceedingly rare that a new Rust version would break older code.
- ithkuil 6y ago
  I think GP meant forward compatibility. New code will use new features and won't compile on old compilers (like other languages)
  - Ar-Curunir 6y ago
    If you updated old compiler with new features, aren't they new compilers?
    - ithkuil 6y ago
      the most charitable reading of GP is not that nobody can ever implement new features in a language but that the 5 month release cycle is causing new features to come in too fast.
serial_dev 6y ago
Backward compatibility doesn't mean that you write code with the latest features, then go back to a version that's a year old than expect it to work. No language or software does that. The promise is that if you have code you didn't touch for a year, you can update Rust, and it will still compile. You got it backwards.

dijit 6y ago

Stop using +nightly. Stable rust hasn't broken in my experience.

superkuh 6y ago
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.
        6y ago
- 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.
deleted 6y ago
[deleted]

pizza234 6y ago

I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, builds fine as well.

steveklabnik 6y ago
I think your comment is good, but also, your comment and the parent comment highlight a situation that makes this discussion hard: you're both talking about two different things. You're talking about using a current compiler to build old code, aka, backwards compatibility. We put a lot of time and effort into this, because it's important, and we're not perfect, but we're pretty darn good at it, it seems. The parent is talking about using an older compiler to build newer code, aka, forwards compatibility. Basically no programming languages I'm aware of provides this today, but they release on a much slower schedule, which means that in practice, it is likely to happen less often. Because Rust ships so often, and because it's so easy to upgrade Rust, the community tends to adopt newer features faster than in other language ecosystems, meaning that forward compatibility becomes more of an issue if you do not want to update the compiler.
- swsieber 6y ago
  To build on this, there are parts of the ecosystem that explicitly outline their Minimum Supported Rust Version. Sometimes it's short (e.g. last two stable releases), and sometimes it's longer (6+ most recent stable releases). What's not well expressed is that is that certain releases prompt a bunch of people to upgrade the newest libraries to require the latest stable release. And these releases are not easily visible or predictable from outside the community. This is driven by Rust releases that stabilize significant features; I'm talking about stuff like async, min const generics, impl trait, proc macro support. So support for older releases tends to wax and wane depending on how recently a big feature was stabilized. There is one other contributing factor - cargo tries to pick the most recent version of library (that's SemVer compliant), not the earliest one, and MSRV changes aren't at this point considered a breaking SemVer change (as far as I know)
- returningfory2 6y ago

csomar 6y ago

That's really weird. So far Rust has been the most stable thing I have worked with. Working with Cargo was a pleasant experience knowing that I will compile any program and the compilation will go smoothly (vs. Python where I have multiple times figure out what went wrong).

otabdeveloper4 6y ago

Don't blaspheme against the FOTM gods. Today is the year of the Rust. Wait until next year when $language is the next shining beacon of not-having-to-deal-with-legacy and Rust itself goes to the dustheap where Cobol and Fortran and Python 3.6 now live.

dave_sid 6y ago
Rust was doomed to fail from the start.
- yjftsjthsd-h 6y ago
  Why?

reificator 6y ago

I don't understand your concern. You're upset that new features are not backported to older compiler versions? If you have some reason to not update your compiler, then don't use those new features, and use dependency versions that also don't use those features. Go back a few releases if you need to. If you do need those features though... Then just upgrade your compiler? I'm not aware of any compilers/interpreters that work the way you want here. Maybe Python 2 for that painful decade of overlap...

mamcx 6y ago

I have done more than dozen of languages and consider Rust the best experience for both "get new shinny things" and "keep old quiet". But the Rust experience IS cargo. No (other) package managers. Rust is cargo centric. With it, you are free to pin to versions and keep things working for very long. BUT also if you are coming cold to any library is to be EXPECTED to be "new". This is a good thing: The community at large move forward in tandem as if it were a coordinated army! But that don't mean I can't work with older code, is that if you see a crate RIGTH NOW you see te forward momentum at large. If you wanna use something older you can pin to a back version. However, this also point to a fair problem: Is not easy to correlate to which version of Rust each crate(version) relate to.

deleted 6y ago
[deleted]

carlosdp 6y ago

That's just blatantly false. Rust takes extreme pains to be backwards compatible. When they wanted to make breaking changes to support some new language features, they literally spun up a separate compiler front-end behind a cargo.toml flag to make sure they didn't break any existing code. Compiler changes are tested against a bunch of libraries in the crates.io repository to ensure nothing breaks. It's just exceedingly rare that a new Rust version would break older code.

ithkuil 6y ago
I think GP meant forward compatibility. New code will use new features and won't compile on old compilers (like other languages)
- Ar-Curunir 6y ago
  If you updated old compiler with new features, aren't they new compilers?
  - ithkuil 6y ago
    the most charitable reading of GP is not that nobody can ever implement new features in a language but that the 5 month release cycle is causing new features to come in too fast.

serial_dev 6y ago

Backward compatibility doesn't mean that you write code with the latest features, then go back to a version that's a year old than expect it to work. No language or software does that. The promise is that if you have code you didn't touch for a year, you can update Rust, and it will still compile. You got it backwards.