By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions.
For example, 1.69 released last week, so now: SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080)
... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program.
If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge.
† And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.
When a language develops quickly it is a good if people use the latest version to test new features to get experience.
When a language become mainstream, change will be much slower. Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
I wouldn't assume that. JavaScript is about as mainstream as it gets, and that's also on a 6-weekly release schedule.
> Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
Rust compilers are already shipped with operating systems, but for the most part (a few really foundational crates aside), people are not writing code that can be compiled by those older compilers. They're telling people to install a newer version of Rust. Which is pretty reasonable given how easy it is to manage rustc versions with rustup.
This may change with the creation of certified compilers for things like the automotive industry. But then, they're probably pretty used to maintaining their own library ecosystem anyway.
> There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
Yes, but one of the best things about Rust is that you can target the latest compiler version, and it still runs everywhere! That's why people don't like the possibility that this might change with the introduction of gcc-rs. We shouldn't accept crappy C toolchains as the standard.
Take for example reproducible builds. Obviously, you only get the same binary output if you use the same compiler version. In that context, it doesn't make sense to keep around every version ever released of the Rust compiler.
In particular, if operating systems are going to use Rust in their kernels or base systems, then it is very unlikely that they are just going to use rustup to get the latest compiler. They will carefully vet each compiler release to make sure that everything that worked in the past, still works.
Rust being a compiler means that for every processor architecture somebody has to create the back-end. This means that if the current LLVM-based rust compiler will remain the only usable Rust compiler, there will be a lot of places where Rust cannot be used (unless LLVM will be the only compiler back-end in the future).
As with Firefox, Linux (ab)uses the compiler's own environment hack to say "No, I want nightly features, I don't care that this invalidates my warranty" despite using a stable compiler.
The actual version used is, I think, currently 1.66 (so, about three months old).
Compiling the Firefox browser is often an exercise in futility because of this.
Rust might be the best but not being able to compile existing programs looks really bad.
> If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work.
How would it not work? If your program compiles and runs with 1.69, then surely that's because it never tries to modify the value. But if your program never tries to modify the value, how would it fail with 1.68?
In this case, the fn `std::net::SocketAddr::new` was made a const fn recently--but was a regular fn before.
>that's because it never tries to modify the value
That's something different. If you want variables that are read-only, you don't need any extra keyword. It's the normal case:
let x = 5;
If you want a mutable variable, you add a `mut` keyword.
let mut x = 5;
But if you want a compile-time constant, you use `const` instead.
const x: u32 = 5;
The latter will be evaluated by the compiler at compile time (so interpreted) and substituted BEFORE the user runs the program. This is new-ish stuff and is slowly worming its way into the standard library.
* Modulo soundness bugs being fixed. I've personally encountered 2 instances of that since 1.0, and they all occurred before 2017.
That's a bold claim for a tool that doesn't even have a Wikipedia entry.
Edit: or a subreddit.
I would implore you to open your mind up to resources that aren't popular social media because that's where the real gold/value is in development/engineering.
I'm not claiming to be "one of the absolutely most valuable and greatest tools available" though. (Well, maybe the "greatest tool" part ;-) And if someone else claimed that about me, I'd think that either there was something very wrong with them, or that one of my parents had started using alt accounts I didn't know about.
Considering some of the software tools that do have dedicated wikipedia pages and subreddits, and that I'd never heard of godbolt before, I don't think it's out of line to be skeptical of such a hyperbolic claim.
Rust is so simple and clear :3
Of course if you just want to convert a string to a SocketAddr (returning an error at runtime if it's invalid), you just do `let addr = "127.0.0.1:8080".parse();`.