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.
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.
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.
Unfortunately HN attracts the very vocal minority...