Build fails with 6 month old rust.
Once it gets to a 1.0, that adoption of new features may slow down.
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.
> 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.
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?
there are plenty of companies when you don't have the right to import any new executable code (coming from "outside") in office computers.
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.
One of the core issues here, imo, is that it is unclear which Rust is the oldest one to be supported. That requires a clarity in understanding the pros and cons of each one, and simply due to there being more releases of rustc, it’s a little less clear which version gets you the most bang for your buck here.
I agree that some of this is a function of the new-ness of the language. I think once (if) we start an LTS program, that will help, and is partially why I desire such a thing. https://rust-lang.github.io/rfcs/2495-min-rust-version.html is an example of a feature we’re adding to help people do this kind of thing. It’s small but it’s a start.
Unfortunately HN attracts the very vocal minority...
(Note also it is the compiler, not a runtime. Big difference when it comes to things like deployments, IMHO.)
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.
In that context, I don’t see the issue with Rust codebases depending on the latest compiler. I understand that it’s done differently with C/C++ and that’s fine. I don’t see why both models can’t work.
The normal philosophy on typical Linux systems is in fact _not_ to require bleeding-edge compiler versions; there’s no “gccup” program. It’s the rust project that is proposing a new and different model.
For example, NEVER install a Python package globally with pip on a Debian System, it WILL conflict with Debian packages (and you'll be very unhappy and confused on the next apt remove or pip uninstall).
It seems that rustup itself is not currently packaged by debian or other linux distros which seems to be a bigger issue. If you could `apt install rustup && rustup install stable` then that seems preferably in pretty much every way to `apt install rust` and getting an old version.
Anyone not doing it this way is just making life needlessly hard for himself and his problems should be ignored entirely.
No. The big deal of Rust 1.0 is that a 6 months old Bevy can compile on the latest version of the compiler. Since new features regularly get added, codebases which use the new features will naturally not work with compiler version predating those features.
It is a concern (as seen with the recent cryptography hubhub), but it's a project-specific concern: projects have to decide on their compiler compatibility range.
Though you could say that it's an ecosystem problem, outside of specific projects I don't think there any sort of badge or way to assert compatibility with specific compiler versions. Since distros are starting to ship rustc (and are unlikely to track the standard mainline), I expect awareness of this issue will grow over time.
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
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-e...
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.
It seemed like an inevitability that some other library would come along that would move forward a bit quicker.