6 ms·

That's right, "the Future". Because as of right now the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features a

That's right, "the Future". Because as of right now the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features at a blinding rate compared to established languages. This makes forwards compatibility so bad that Debian 11, which isn't even released yet and has rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later. It's not that Rust is bad, it's great. But right now the dev culture is all about $latest and there aren't many Rust devs that care if you can compile and run it on your 2 year old distro. This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date.

cogman10 5y ago
> Debian 11, which isn't even released yet and has rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later. This comes up with Java as well. Lots of distros ship with "java X" and ignore the version march. Ultimately you end up going around package management if you want to stay up to date. I'm not sure the best way to fix this. A lot of distros want to treat everything like they treat GCC and C++. C++ which releases new versions every 3 years or so which means that having a version of GCC 1 or 2 years out of date doesn't generally matter. > the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features at a blinding rate compared to established languages. A major complaint I have about rust devs is so many libs require nightly rust. That, IMO, is inexcusable. Sure, it's ok to try out those features, but why are you publishing libraries that REQUIRE those features to work? That seems like just a generally bad idea. > This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date. With browser and Java that's already the case so I don't see this as an issue with rust. I'm not sure the best way to solve this, but I hardly think it's a rust issue so much as it's a problem with how dependency management works today.
- steveklabnik 5y ago
  What libraries still hit that nightly pain for you today?
  - cogman10 5y ago
    https://github.com/master-of-zen/Av1an https://github.com/master-of-zen/Av1an just required it. Not technically a library but it's on my mind. Rocket still uses nightly https://rocket.rs/v0.4/guide/getting-started/ https://rocket.rs/v0.4/guide/getting-started/ Not sure about others but those are the two I think of. It's usually something that comes up when I start playing with rust and want to do X. Last few times I've done that the nightly requirement hits.
    - pie_flavor 5y ago
      Rocket publishes a library that requires nightly features to work because the alternative is not publishing the library that requires nightly features to work. I'm not sure what you think you're losing by the library existing on crates.io, but there really isn't a way of doing what rocket does without nightly. If there were, Rocket would be doing it (and stabilization for its features is fast approaching).
    - steveklabnik 5y ago
      Thanks. It’s always good to know. I rarely run into this anymore, so different perspectives are useful. (Rocket’s master branch doesn’t require nightly but they haven’t released yet, incidentally.)
  - papaf 5y ago
    Packed SIMD [1] can be a pain because it pops up as a transitive dependency [2]. [1] https://github.com/rust-lang/packed_simd/blob/master/rust-toolchain https://github.com/rust-lang/packed_simd/blob/master/rust-to... [2] https://crates.io/crates/packed_simd_2/reverse_dependencies https://crates.io/crates/packed_simd_2/reverse_dependencies
- throwaway894345 5y ago
gher-shyu3i 5y ago
> Debian 11, which isn't even released yet and has rustc 1.48 Why is that an issue? Several languages now have fast releases, including Java and golang at twice a year, and C# at once a year. It's best practice to always use the latest version of the compiler.
- rapsey 5y ago
  > Why is that an issue? It isn't. It is an issue only linux zealots care about. They are of course a vocal minority online as always.
pixel_fcker 5y ago
> rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later. What are you talking about?
- steveklabnik 5y ago
  Rust 1.48 was released in November 2020. Rust 1.49 was released six weeks later. Rust is backwards compatible but not forward compatible, so programs that use features released in 1.49 would not compile with 1.48. (The current release is 1.52.1)
  - kklisura 5y ago
    Do you know any languages which are forward compatible?
    - superkuh 5y ago
      It isn't about the language, although Rust being new and adding new features makes it worse. It is about the developer culture. So, do I know a language with a developer culture that is forwards compatible? Yes. Bash. It regularly gets new features added (surprising, I know). But Bash devs know that their users won't always have the bleeding edge and don't use $latest stuff as soon as it's released.
      - riquito 5y ago
        > But Bash devs know that their users won't always have the bleeding edge and don't use $latest stuff as soon as it's released. Frankly, it's more that we have no idea which shell (nevermind the version) the code will run onto and keep on relying on old api and luck...
    - worik 5y ago
      ....that would be a trick!
dimitrios1 5y ago
Right, and add on top of this the hubris has towards the topic of an official specification. Simply asking the question if one is being considered or worked on gets you scoffed at, as if you were some unenlightened simpleton. "Look at all of these other languages without one!" they remark. How does this help the discourse? I think what describes rust perfectly to me, at least at this time, is the red box here https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/ -- something that no matter how many times undergoes a release, still feels incomplete. And for the record, I am someone very interested in using rust at work. Just can't until it stops feeling like an experiment.
- steveklabnik 5y ago
  I am sorry you’ve had that experience. The position of the project has been “we would like one, but we want to do one right, and that will take time.” Millions of Euros and years of work have been poured into this. It is something we care about.
  - mjw1007 5y ago
    I think you can measure what a project cares about by the priorities they give to different pieces of work. Empirically, since 1.0 the project as a whole has prioritised adding new features over documenting (and agreeing the intended behaviour of) existing ones. In early 2019, the roadmap said the language team would make updating the reference a priority that year. But as far as I can tell nothing happened, and it hasn't appeared on the roadmap since then.
    - steveklabnik 5y ago
      Yes, as it turns out, open source projects cannot dictate what people work on to the same degree as companies, and there are far more people willing to do non-spec work. Those efforts aren't fungible though; progress has been made on both fronts, the spec work is just far less visible. "is important" != "the most important thing"
  - dimitrios1 5y ago
timw4mail 5y ago
Having to be stuck on an OS-version of a language should be an old-fashioned issue. Rust, PHP, NodeJS, are a few of the languages I never use from the OS repos, exactly because they are always behind.
throwaway894345 5y ago
> This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date. I don't see the problem. This seems like further evidence that distro package managers aren't the way forward. They can't keep up, they rarely have a sufficiently broad or up-to-date collection of packages, and when you integrate third party channels it can break other software ("run 'apt-get -f' to fix your dependencies" has never ever worked for me). Generally language-specific package managers work just fine.
- zxzax 5y ago
  That really has nothing to do with language-specific versus distro packaging. If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage.
  - throwaway894345 5y ago
    > If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage. I wouldn't need to do that in Rust because Rust programs are typically statically compiled. If I install some third-party program, it doesn't break a bunch of software that I installed via `cargo install`, nor does it prevent me from `cargo install`ing new packages (whether or not I can install a given package doesn't depend on the state of the packages that are already installed on my system). Maybe the real reason that distro package managers are unpleasant is that they opt to dynamically link everything by default?
    - zxzax 5y ago
      You can also statically link debian packages, though conventionally they aren't built like that.
    - bombela 5y ago
      > Maybe the real reason that distro package managers are unpleasant is that they opt to dynamically link everything by default? This. Seriously if things weren't such a tangled mess. I could just do `apt install potato@v2.1` and life would just be so good and simple.
worik 5y ago
I completely agree. Rust is still very new. As a Rust fan I want a Rust 2.0. Smaller, specified, and stable. But it is not, quite, time yet.
- nindalf 5y ago
  Don’t wait for a Rust 2.0. It will likely never happen. Especially since the Edition system allows for the language to add opt-in breaking changes. If you want a Rust that’s easier to learn - work is constantly happening to make that a reality.
  - worik 5y ago
    They have promised there will be no 2.0. So I am not waiting. It is what I desire.
    - nindalf 5y ago
      What will it get you? A smaller rust that breaks compatibility with all existing Rust software wouldn’t be Rust anymore. https://without.boats/blog/notes-on-a-smaller-rust/ https://without.boats/blog/notes-on-a-smaller-rust/
nindalf 5y ago
Are you talking about an actual issue you faced or are you complaining about something that might have happened hypothetically? Was there some dependency of your code that changed its minimum supported rust version (MSRV) to 1.51? What puzzles me is whether this affects people at all. Let’s say a developer depends on crate foo, version 0.6, MSRV 1.39. Their Cargo.lock file specifies that they depend on version 0.6. Their code will now compile correctly and continue to do so between now and the heat death of the universe. Of course it’s possible that they want to keep manually upgrading their version of foo to the latest and greatest. They have the option of doing so. But here’s what puzzles me - they seem to be very conservative with upgrading their compiler but carefree about upgrading dependencies. Why not stay on the foo version that was working well? Who is this hypothetical developer who is desperate to upgrade their dep and equally desperate not to run a single command to upgrade their compiler? More broadly, I find it surprising that package managers have no trouble keeping up with the release cycles of Firefox and Chromium (6 week releases) but can’t keep up with Rust.
Animats 5y ago
About three years ago, it really was that bad. Now, the language is reasonably stable. There's far less that "only works in nightly". Crates, though, still show quite a bit of churn. Recently I ran into an effort to make all types fit the Rust capitalization form. Like changing "DNS" to "Dns", breaking various things along the way. Also, the Cargo and crate system encourages version pinning to the minor version level, which can lead to the modern equivalent of DLL hell. Many important crates are still at the 0.x.x level, which, if you take semantic versioning seriously, means no guarantee that the API will not change if the minor version does. I have some theoretical arguments about the language, but overall, Rust is way ahead of anything else in this space. I didn't think you could push the ownership model this hard and still have a usable language. But you can. I'm 30,000 lines into a project and have not had to write "unsafe" once.
mlindner 5y ago
> Rust adds $latest features at a blinding rate compared to established languages Please don't repeat misinformation you only heard in a hacker news comment.

cogman10 5y ago

> Debian 11, which isn't even released yet and has rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later. This comes up with Java as well. Lots of distros ship with "java X" and ignore the version march. Ultimately you end up going around package management if you want to stay up to date. I'm not sure the best way to fix this. A lot of distros want to treat everything like they treat GCC and C++. C++ which releases new versions every 3 years or so which means that having a version of GCC 1 or 2 years out of date doesn't generally matter. > the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features at a blinding rate compared to established languages. A major complaint I have about rust devs is so many libs require nightly rust. That, IMO, is inexcusable. Sure, it's ok to try out those features, but why are you publishing libraries that REQUIRE those features to work? That seems like just a generally bad idea. > This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date. With browser and Java that's already the case so I don't see this as an issue with rust. I'm not sure the best way to solve this, but I hardly think it's a rust issue so much as it's a problem with how dependency management works today.

steveklabnik 5y ago
What libraries still hit that nightly pain for you today?
- cogman10 5y ago
  https://github.com/master-of-zen/Av1an https://github.com/master-of-zen/Av1an just required it. Not technically a library but it's on my mind. Rocket still uses nightly https://rocket.rs/v0.4/guide/getting-started/ https://rocket.rs/v0.4/guide/getting-started/ Not sure about others but those are the two I think of. It's usually something that comes up when I start playing with rust and want to do X. Last few times I've done that the nightly requirement hits.
  - pie_flavor 5y ago
    Rocket publishes a library that requires nightly features to work because the alternative is not publishing the library that requires nightly features to work. I'm not sure what you think you're losing by the library existing on crates.io, but there really isn't a way of doing what rocket does without nightly. If there were, Rocket would be doing it (and stabilization for its features is fast approaching).
  - steveklabnik 5y ago
    Thanks. It’s always good to know. I rarely run into this anymore, so different perspectives are useful. (Rocket’s master branch doesn’t require nightly but they haven’t released yet, incidentally.)
- papaf 5y ago
  Packed SIMD [1] can be a pain because it pops up as a transitive dependency [2]. [1] https://github.com/rust-lang/packed_simd/blob/master/rust-toolchain https://github.com/rust-lang/packed_simd/blob/master/rust-to... [2] https://crates.io/crates/packed_simd_2/reverse_dependencies https://crates.io/crates/packed_simd_2/reverse_dependencies
throwaway894345 5y ago

gher-shyu3i 5y ago

> Debian 11, which isn't even released yet and has rustc 1.48 Why is that an issue? Several languages now have fast releases, including Java and golang at twice a year, and C# at once a year. It's best practice to always use the latest version of the compiler.

rapsey 5y ago
> Why is that an issue? It isn't. It is an issue only linux zealots care about. They are of course a vocal minority online as always.

pixel_fcker 5y ago

> rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later. What are you talking about?

steveklabnik 5y ago
Rust 1.48 was released in November 2020. Rust 1.49 was released six weeks later. Rust is backwards compatible but not forward compatible, so programs that use features released in 1.49 would not compile with 1.48. (The current release is 1.52.1)
- kklisura 5y ago
  Do you know any languages which are forward compatible?
  - superkuh 5y ago
    It isn't about the language, although Rust being new and adding new features makes it worse. It is about the developer culture. So, do I know a language with a developer culture that is forwards compatible? Yes. Bash. It regularly gets new features added (surprising, I know). But Bash devs know that their users won't always have the bleeding edge and don't use $latest stuff as soon as it's released.
    - riquito 5y ago
      > But Bash devs know that their users won't always have the bleeding edge and don't use $latest stuff as soon as it's released. Frankly, it's more that we have no idea which shell (nevermind the version) the code will run onto and keep on relying on old api and luck...
  - worik 5y ago
    ....that would be a trick!

dimitrios1 5y ago

Right, and add on top of this the hubris has towards the topic of an official specification. Simply asking the question if one is being considered or worked on gets you scoffed at, as if you were some unenlightened simpleton. "Look at all of these other languages without one!" they remark. How does this help the discourse? I think what describes rust perfectly to me, at least at this time, is the red box here https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/ -- something that no matter how many times undergoes a release, still feels incomplete. And for the record, I am someone very interested in using rust at work. Just can't until it stops feeling like an experiment.

steveklabnik 5y ago
I am sorry you’ve had that experience. The position of the project has been “we would like one, but we want to do one right, and that will take time.” Millions of Euros and years of work have been poured into this. It is something we care about.
- mjw1007 5y ago
  I think you can measure what a project cares about by the priorities they give to different pieces of work. Empirically, since 1.0 the project as a whole has prioritised adding new features over documenting (and agreeing the intended behaviour of) existing ones. In early 2019, the roadmap said the language team would make updating the reference a priority that year. But as far as I can tell nothing happened, and it hasn't appeared on the roadmap since then.
  - steveklabnik 5y ago
    Yes, as it turns out, open source projects cannot dictate what people work on to the same degree as companies, and there are far more people willing to do non-spec work. Those efforts aren't fungible though; progress has been made on both fronts, the spec work is just far less visible. "is important" != "the most important thing"
- dimitrios1 5y ago

timw4mail 5y ago

Having to be stuck on an OS-version of a language should be an old-fashioned issue. Rust, PHP, NodeJS, are a few of the languages I never use from the OS repos, exactly because they are always behind.

throwaway894345 5y ago

> This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date. I don't see the problem. This seems like further evidence that distro package managers aren't the way forward. They can't keep up, they rarely have a sufficiently broad or up-to-date collection of packages, and when you integrate third party channels it can break other software ("run 'apt-get -f' to fix your dependencies" has never ever worked for me). Generally language-specific package managers work just fine.

zxzax 5y ago
That really has nothing to do with language-specific versus distro packaging. If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage.
- throwaway894345 5y ago
  > If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage. I wouldn't need to do that in Rust because Rust programs are typically statically compiled. If I install some third-party program, it doesn't break a bunch of software that I installed via `cargo install`, nor does it prevent me from `cargo install`ing new packages (whether or not I can install a given package doesn't depend on the state of the packages that are already installed on my system). Maybe the real reason that distro package managers are unpleasant is that they opt to dynamically link everything by default?
  - zxzax 5y ago
    You can also statically link debian packages, though conventionally they aren't built like that.
  - bombela 5y ago
    > Maybe the real reason that distro package managers are unpleasant is that they opt to dynamically link everything by default? This. Seriously if things weren't such a tangled mess. I could just do `apt install potato@v2.1` and life would just be so good and simple.

worik 5y ago

I completely agree. Rust is still very new. As a Rust fan I want a Rust 2.0. Smaller, specified, and stable. But it is not, quite, time yet.

nindalf 5y ago
Don’t wait for a Rust 2.0. It will likely never happen. Especially since the Edition system allows for the language to add opt-in breaking changes. If you want a Rust that’s easier to learn - work is constantly happening to make that a reality.
- worik 5y ago
  They have promised there will be no 2.0. So I am not waiting. It is what I desire.
  - nindalf 5y ago
    What will it get you? A smaller rust that breaks compatibility with all existing Rust software wouldn’t be Rust anymore. https://without.boats/blog/notes-on-a-smaller-rust/ https://without.boats/blog/notes-on-a-smaller-rust/

nindalf 5y ago

Are you talking about an actual issue you faced or are you complaining about something that might have happened hypothetically? Was there some dependency of your code that changed its minimum supported rust version (MSRV) to 1.51? What puzzles me is whether this affects people at all. Let’s say a developer depends on crate foo, version 0.6, MSRV 1.39. Their Cargo.lock file specifies that they depend on version 0.6. Their code will now compile correctly and continue to do so between now and the heat death of the universe. Of course it’s possible that they want to keep manually upgrading their version of foo to the latest and greatest. They have the option of doing so. But here’s what puzzles me - they seem to be very conservative with upgrading their compiler but carefree about upgrading dependencies. Why not stay on the foo version that was working well? Who is this hypothetical developer who is desperate to upgrade their dep and equally desperate not to run a single command to upgrade their compiler? More broadly, I find it surprising that package managers have no trouble keeping up with the release cycles of Firefox and Chromium (6 week releases) but can’t keep up with Rust.

Animats 5y ago

About three years ago, it really was that bad. Now, the language is reasonably stable. There's far less that "only works in nightly". Crates, though, still show quite a bit of churn. Recently I ran into an effort to make all types fit the Rust capitalization form. Like changing "DNS" to "Dns", breaking various things along the way. Also, the Cargo and crate system encourages version pinning to the minor version level, which can lead to the modern equivalent of DLL hell. Many important crates are still at the 0.x.x level, which, if you take semantic versioning seriously, means no guarantee that the API will not change if the minor version does. I have some theoretical arguments about the language, but overall, Rust is way ahead of anything else in this space. I didn't think you could push the ownership model this hard and still have a usable language. But you can. I'm 30,000 lines into a project and have not had to write "unsafe" once.

mlindner 5y ago

> Rust adds $latest features at a blinding rate compared to established languages Please don't repeat misinformation you only heard in a hacker news comment.