7 ms·

Build fails with 6 month old rust.

by fctorial 6y ago

richardwhiuk 6y ago
And?
- fctorial 6y ago
  Most C/C++ projects do compile if you use a 6 month old compiler.
  - rapsey 6y ago
    So what?
    - linkdd 6y ago
      If you think the whole world of IT works on bleeding edge tech, you're mistaken. Most distributions have an LTS that is supported for 5 to 10 years. You won't get the newest, hottest compiler on those platforms. > So what? Rust is a great language, but y'all need to calm down with the hype. "Not Rust" != evil.
      - Tuna-Fish 6y ago
        For as long as Rust has existed, no-one who is writing rust actually wants to use a compiler version that's any older than the newest. The language keeps adding good stuff in every version. I thought it would calm down a bit after NLL, but now everyone is salivating for const generics, which will land in 1.41... and in a whole lot of versions after that, as they split up the feature into smaller, easier to implement and study chunks. The language simply hasn't reached the level of maturity of C++ where people yawn at the new features that are going to be added. > Most distributions have an LTS that is supported for 5 to 10 years. You won't get the newest, hottest compiler on those platforms. Yes, you do, because you won't be using the distribution-supplied compiler because like the entire rest of the rust developer community you are using rustup.
        linkdd 6y ago
        What if you're in a constrained environment, there is no rustup installed, and you don't have the permissions to install it? This issue certainly occurred with a lot of C/C++ projects over the past 30 years, why would Rust be exempt of that issue in the future?
        rapsey 6y ago
        If someone is working in an insane environment then that is his problem and also highly unlikely to be using Rust anyway. Why should library developers care about keeping compatibility with old Rust compiler versions for some arbitrary amount of time?
        sanxiyn 6y ago
        That's easy to answer. Because users want that. Of course developers are free to ignore such users, and such users will choose a different library.
        Ar-Curunir 6y ago
        rustup is installed within the user's home directory. If you can't write to your own home, then what can you do on this device that involves compiling code?
        jcelerier 6y ago
        > rustup is installed within the user's home directory. If you can't write to your own home, then what can you do on this device that involves compiling code? there are plenty of companies when you don't have the right to import any new executable code (coming from "outside") in office computers.
        linkdd 6y ago
        Small example in one of my previous job: Application was built using Java/SpringBoot, and the CI/CD was based on Jenkins. We had no control over the version of maven/jdk installed within the Jenkins, and the network policies did not authorize outgoing traffic (so no curling rustup). Only one company repository (based on Nexus) was available. Basically, we were users of a company provided/constrained platform to build our applications using a curated list of tools that has been audited by another team. If we wanted to add a dependency not present in the provided repository, it would require time for the audit and integration. Time we did not necessarily had. Now, with Rust/rustup/Cargo, the company would have provided a specific set of Rust versions and a private crate repository. I doubt that the auditing team would have time to add a new Rust version every week. If a crate present on the private repository is updated upstream and requires a more recent Rust version, the crate update will be delayed until the Rust version is audited/validated/integrated. IMHO, this is a very common use case, since companies like to split concerns in different specialized teams.
      - nindalf 6y ago
        Anyone developing games with this project is likely to be on Windows, Linux or Mac, on x64 or aarch64. Such developers would likely install Rust with rustup, not with the distro provided one. So yes, any developer that fits this description can rely on the newest, hottest compiler.
        linkdd 6y ago
        And that's perfectly fine. But game developers are a small fractions of Rust developers.
        _joel 6y ago
        I think most devs use rustup, not the distro supplied one.
        3836293648 6y ago
        Is rustc even in the repos? Should it (and cargo) be? Or should they just have rustup? I lean towards the latter
        steveklabnik 6y ago
        rustc is in pretty much every distro's repos at this point. They often have Cargo too. They sometimes, but not always, have rustup.
        maccam94 6y ago
        Some distros ship programs compiled with rust, and they do so using the version of rustc in the repo.
        nicoburns 6y ago
        Right, but it's this specific project that requires the latest Rust compiler, not Rust libraries in general.
      - eeZah7Ux 6y ago
        > If you think the whole world of IT works on bleeding edge tech, you're mistaken. Unfortunately HN attracts the very vocal minority...
  - ironmagma 6y ago
    Part of the reason Rust is still fun is that it hasn’t hit the point yet where everything has to worry about backwards compatibility. Let’s keep it that way as long as possible.
    - Thaxll 6y ago
      This kind of comment is worrying, I would never choose a library / framework if I had to upgrade the runtime every 3 month.
      - steveklabnik 6y ago
        You don’t have to. If you want to depend on other people’s code, they may use new features, which may require a newer compiler. But you are in full control there; you are not forced to upgrade. (Note also it is the compiler, not a runtime. Big difference when it comes to things like deployments, IMHO.)
      - hctaw 6y ago
        Rust doesn't have a runtime so you're good
        ironmagma 6y ago
        Rust does have a runtime, but it's statically linked. https://doc.rust-lang.org/reference/runtime.html https://doc.rust-lang.org/reference/runtime.html
        steveklabnik 6y ago
        "runtime" is a term that has conflicting colloquial and precise definitions. In a precise sense, any non-assembly language, including C, has a runtime. In practice, this makes the term "runtime" not super useful to many folks, so they mean "virtual machine" or "large, featureful runtime that's required to support critical language features" when they say "runtime." Rust is the same as C in this regard. It technically has a runtime, but not in the way that many people mean.
- flohofwoe 6y ago
  Wasn't this a big deal when Rust hit version 1.0 [1]? There's a lot of reasons for not being able to use a bleeding edge compiler version. [1] https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html
  - Macha 6y ago
    They promised improvements in keeping backwards compatibility, i.e. building old code on new rust. No one promised forward compatibility, building new code on old rust.
    - flohofwoe 6y ago
      Yeah ok, makes sense of course. It's still a somewhat strange decision on the project's part. It's basically similar to using C++20 features only six months after the first C++ compilers support C++20. If that's a one-time thing during development of the framework it's probably fine. But if in 5 years the project still reqiures a less than 6-months old compiler version, I'd be worried ;)
      - nicoburns 6y ago
        Why? The advantage of having a single Rust compiler is that there is almost never any reason to use an old one. There are some cases where I can see that using a pinned compiler version would be important: if you are doing mission-critical embedded or financial programming and need a verified compiler. But none of those apply to game development.
        flohofwoe 6y ago
        I see having a single compiler instead of multiple competing compilers more as a bug than a feature, at least in the long run. It's fine as long as the language is in "exploration phase", but hopefully we'll see more independent Rust compilers in the future (e.g. https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs)
rapsey 6y ago
Why would you use 6 month old rust?
- nindalf 6y ago
  Some OS-arch combinations might not have the latest one available. This is an issue for OSes that aren’t Windows, Mac or Linux and architectures that aren’t x64 or aarch64.
  - rapsey 6y ago
    Any developer relying on OS provided rust installation is just making life needlessly complicated for himself.
    - nindalf 6y ago
      I agree, but if a developer is developing on a tier 2 or tier 3 platform, they can’t necessarily rely on rustup either.
      - Ar-Curunir 6y ago
        but how many of these folks are compiling bevy on these tier 2 platforms?
    - sanxiyn 6y ago
      I agree it should be avoided if possible, but sometimes it can't be avoided.
- drran 6y ago
  Distribution does integration. It's better to use a bit older version, but properly integrated with other parts of the system.
  - rapsey 6y ago
    That is completely pointless for a rust compiler. What are they going to integrate.
Macha 6y ago
It's competitor, Amethyst, fails to build on Linux with current Rust. I think it's something to do with outdated dependencies of winit running into namespacing issues with macros that were added to the standard library
- yazaddaruvala 6y ago
  I was under the impression that Amethyst was not a competitor. There was a post stating Amethyst was basically in need of a re-architecture that could never be resourced and because Bevy was already based on that “new” architecture it was easier to switch all development effort over. But maybe this thread is out of date. https://community.amethyst.rs/t/bevy-engine-addressing-the-elephant-in-the-room/1645 https://community.amethyst.rs/t/bevy-engine-addressing-the-e...
  - Macha 6y ago
    Certainly that rewrite was huge, and it is currently "mostly complete", but Bevy launching when it did helped stifle a lot of the momentum. However, it was picked back up again in November and is now mostly complete: https://github.com/amethyst/amethyst/issues/2517 https://github.com/amethyst/amethyst/issues/2517 From outside at this point, the rewrite looks like a mistake , given the lost momentum and the current state of the project, but maybe when they finally get it out it'll turn out differently in 6 months.
    - royjacobs 6y ago
      This may come off as snarky, but as long as I've been following Rust and Amethyst the latter seems to always be in some kind of "not quite there yet but it will be after the next rewrite/rearchitecture". Same goes for Conrod, its GUI library. It seemed like an inevitability that some other library would come along that would move forward a bit quicker.
pacificat0r 6y ago
It's not surprising that a project that's really early in development chooses to keep up with the latest rust as a min. reqirement. Once it gets to a 1.0, that adoption of new features may slow down.

Build fails with 6 month old rust.

richardwhiuk 6y ago

And?

fctorial 6y ago
Most C/C++ projects do compile if you use a 6 month old compiler.
- rapsey 6y ago
  So what?
  - linkdd 6y ago
    If you think the whole world of IT works on bleeding edge tech, you're mistaken. Most distributions have an LTS that is supported for 5 to 10 years. You won't get the newest, hottest compiler on those platforms. > So what? Rust is a great language, but y'all need to calm down with the hype. "Not Rust" != evil.
    - Tuna-Fish 6y ago
      For as long as Rust has existed, no-one who is writing rust actually wants to use a compiler version that's any older than the newest. The language keeps adding good stuff in every version. I thought it would calm down a bit after NLL, but now everyone is salivating for const generics, which will land in 1.41... and in a whole lot of versions after that, as they split up the feature into smaller, easier to implement and study chunks. The language simply hasn't reached the level of maturity of C++ where people yawn at the new features that are going to be added. > Most distributions have an LTS that is supported for 5 to 10 years. You won't get the newest, hottest compiler on those platforms. Yes, you do, because you won't be using the distribution-supplied compiler because like the entire rest of the rust developer community you are using rustup.
      - linkdd 6y ago
        What if you're in a constrained environment, there is no rustup installed, and you don't have the permissions to install it? This issue certainly occurred with a lot of C/C++ projects over the past 30 years, why would Rust be exempt of that issue in the future?
        rapsey 6y ago
        If someone is working in an insane environment then that is his problem and also highly unlikely to be using Rust anyway. Why should library developers care about keeping compatibility with old Rust compiler versions for some arbitrary amount of time?
        sanxiyn 6y ago
        That's easy to answer. Because users want that. Of course developers are free to ignore such users, and such users will choose a different library.
        Ar-Curunir 6y ago
        rustup is installed within the user's home directory. If you can't write to your own home, then what can you do on this device that involves compiling code?
        jcelerier 6y ago
        > rustup is installed within the user's home directory. If you can't write to your own home, then what can you do on this device that involves compiling code? there are plenty of companies when you don't have the right to import any new executable code (coming from "outside") in office computers.
        linkdd 6y ago
        Small example in one of my previous job: Application was built using Java/SpringBoot, and the CI/CD was based on Jenkins. We had no control over the version of maven/jdk installed within the Jenkins, and the network policies did not authorize outgoing traffic (so no curling rustup). Only one company repository (based on Nexus) was available. Basically, we were users of a company provided/constrained platform to build our applications using a curated list of tools that has been audited by another team. If we wanted to add a dependency not present in the provided repository, it would require time for the audit and integration. Time we did not necessarily had. Now, with Rust/rustup/Cargo, the company would have provided a specific set of Rust versions and a private crate repository. I doubt that the auditing team would have time to add a new Rust version every week. If a crate present on the private repository is updated upstream and requires a more recent Rust version, the crate update will be delayed until the Rust version is audited/validated/integrated. IMHO, this is a very common use case, since companies like to split concerns in different specialized teams.
    - nindalf 6y ago
      Anyone developing games with this project is likely to be on Windows, Linux or Mac, on x64 or aarch64. Such developers would likely install Rust with rustup, not with the distro provided one. So yes, any developer that fits this description can rely on the newest, hottest compiler.
      - linkdd 6y ago
        And that's perfectly fine. But game developers are a small fractions of Rust developers.
        _joel 6y ago
        I think most devs use rustup, not the distro supplied one.
        3836293648 6y ago
        Is rustc even in the repos? Should it (and cargo) be? Or should they just have rustup? I lean towards the latter
        steveklabnik 6y ago
        rustc is in pretty much every distro's repos at this point. They often have Cargo too. They sometimes, but not always, have rustup.
        maccam94 6y ago
        Some distros ship programs compiled with rust, and they do so using the version of rustc in the repo.
        nicoburns 6y ago
        Right, but it's this specific project that requires the latest Rust compiler, not Rust libraries in general.
    - eeZah7Ux 6y ago
      > If you think the whole world of IT works on bleeding edge tech, you're mistaken. Unfortunately HN attracts the very vocal minority...
- ironmagma 6y ago
  Part of the reason Rust is still fun is that it hasn’t hit the point yet where everything has to worry about backwards compatibility. Let’s keep it that way as long as possible.
  - Thaxll 6y ago
    This kind of comment is worrying, I would never choose a library / framework if I had to upgrade the runtime every 3 month.
    - steveklabnik 6y ago
      You don’t have to. If you want to depend on other people’s code, they may use new features, which may require a newer compiler. But you are in full control there; you are not forced to upgrade. (Note also it is the compiler, not a runtime. Big difference when it comes to things like deployments, IMHO.)
    - hctaw 6y ago
      Rust doesn't have a runtime so you're good
      - ironmagma 6y ago
        Rust does have a runtime, but it's statically linked. https://doc.rust-lang.org/reference/runtime.html https://doc.rust-lang.org/reference/runtime.html
        steveklabnik 6y ago
        "runtime" is a term that has conflicting colloquial and precise definitions. In a precise sense, any non-assembly language, including C, has a runtime. In practice, this makes the term "runtime" not super useful to many folks, so they mean "virtual machine" or "large, featureful runtime that's required to support critical language features" when they say "runtime." Rust is the same as C in this regard. It technically has a runtime, but not in the way that many people mean.
flohofwoe 6y ago
Wasn't this a big deal when Rust hit version 1.0 [1]? There's a lot of reasons for not being able to use a bleeding edge compiler version. [1] https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html
- Macha 6y ago
  They promised improvements in keeping backwards compatibility, i.e. building old code on new rust. No one promised forward compatibility, building new code on old rust.
  - flohofwoe 6y ago
    Yeah ok, makes sense of course. It's still a somewhat strange decision on the project's part. It's basically similar to using C++20 features only six months after the first C++ compilers support C++20. If that's a one-time thing during development of the framework it's probably fine. But if in 5 years the project still reqiures a less than 6-months old compiler version, I'd be worried ;)
    - nicoburns 6y ago
      Why? The advantage of having a single Rust compiler is that there is almost never any reason to use an old one. There are some cases where I can see that using a pinned compiler version would be important: if you are doing mission-critical embedded or financial programming and need a verified compiler. But none of those apply to game development.
      - flohofwoe 6y ago
        I see having a single compiler instead of multiple competing compilers more as a bug than a feature, at least in the long run. It's fine as long as the language is in "exploration phase", but hopefully we'll see more independent Rust compilers in the future (e.g. https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs)

rapsey 6y ago

Why would you use 6 month old rust?

nindalf 6y ago
Some OS-arch combinations might not have the latest one available. This is an issue for OSes that aren’t Windows, Mac or Linux and architectures that aren’t x64 or aarch64.
- rapsey 6y ago
  Any developer relying on OS provided rust installation is just making life needlessly complicated for himself.
  - nindalf 6y ago
    I agree, but if a developer is developing on a tier 2 or tier 3 platform, they can’t necessarily rely on rustup either.
    - Ar-Curunir 6y ago
      but how many of these folks are compiling bevy on these tier 2 platforms?
  - sanxiyn 6y ago
    I agree it should be avoided if possible, but sometimes it can't be avoided.
drran 6y ago
Distribution does integration. It's better to use a bit older version, but properly integrated with other parts of the system.
- rapsey 6y ago
  That is completely pointless for a rust compiler. What are they going to integrate.

Macha 6y ago

It's competitor, Amethyst, fails to build on Linux with current Rust. I think it's something to do with outdated dependencies of winit running into namespacing issues with macros that were added to the standard library

yazaddaruvala 6y ago
I was under the impression that Amethyst was not a competitor. There was a post stating Amethyst was basically in need of a re-architecture that could never be resourced and because Bevy was already based on that “new” architecture it was easier to switch all development effort over. But maybe this thread is out of date. https://community.amethyst.rs/t/bevy-engine-addressing-the-elephant-in-the-room/1645 https://community.amethyst.rs/t/bevy-engine-addressing-the-e...
- Macha 6y ago
  Certainly that rewrite was huge, and it is currently "mostly complete", but Bevy launching when it did helped stifle a lot of the momentum. However, it was picked back up again in November and is now mostly complete: https://github.com/amethyst/amethyst/issues/2517 https://github.com/amethyst/amethyst/issues/2517 From outside at this point, the rewrite looks like a mistake , given the lost momentum and the current state of the project, but maybe when they finally get it out it'll turn out differently in 6 months.
  - royjacobs 6y ago
    This may come off as snarky, but as long as I've been following Rust and Amethyst the latter seems to always be in some kind of "not quite there yet but it will be after the next rewrite/rearchitecture". Same goes for Conrod, its GUI library. It seemed like an inevitability that some other library would come along that would move forward a bit quicker.

pacificat0r 6y ago

It's not surprising that a project that's really early in development chooses to keep up with the latest rust as a min. reqirement. Once it gets to a 1.0, that adoption of new features may slow down.