Fair words to the Rust community

As a beginner I can say that the cycles do not impact the study materials, the only notable impact is between the language versions, such as Rust 2015 and 2018.
What was valid in Rust 2015 as information about module organizations using mod.rs for everything, and some syntaxes like using dyn without box were well outdated and may leave you lost in Rust 2018 but this is normal.

I agree. I think the rust community speak too little about the stability within an edition. It's quite easy to see how often there's a new version of rust in your package system, and that might lead to a scare of breaking newness. But, the fact is within an edition most learning material works just fine. Emphasizing the stability of the editions might be a good marketing move.

I just hope people would stop running 'nightly' for anything they ship publicly. That's where I feel there's a danger.

1 Like

Note that this is not limited to Rust. I recall when I upgraded to Java 9, I had to change a bunch of code because _ was no longer a valid identifier.

Incidentally, Java makes great efforts towards backwards compatibility at the bytecode level, but even that it is not absolute. They recently got rid of an undocumented JVM feature for backwards compatibility with extremely early bytecode versions, presumably under the assumption that noone was actually using it.

1 Like

Actually, Rust's development cycle reminds me very much of Java. The JDK, like Rust, has new feature updates every 6 months. However, most Java applications remain on LTS releases which come out every 3 years (similar to Rust's editions). The JDK authors do their best to maintain binary compatibility but sometimes break source compatibility. Like Rust, they are willing to make source-incompatible changes. However, you can compile old code through a compiler settings, again similarly to Rust.

1 Like

When I first started using Rust, circa 2017, I quickly found that features I needed/wanted fell into a few categories:

  1. This is in Rust today, and it's fantastic!
  2. This isn't in Rust yet, but if I use Nightly I can have it today and it's... great.
  3. This isn't in Rust yet, but there's an RFC for it that looks promising.
  4. This isn't in Rust and won't be for the foreseeable future.

There was a pretty even spread across tiers 1 through 3 and a few things in 4. In particular, there were several features that I "needed" in tier 2, so I was forced to use Nightly just to do certain things at all.

Since then, I've watched an exhilarating landslide take place. Month to month, features migrate up the tiers. I can't think of any 4s left, and just in the last year I've personally observed important features on their migration from 3 to 2 to 1. And, today, when I run into a new obstacle, and think "I could really use a certain feature here", instead of often finding it at 3 or 4, I'm more likely to find a 1 I didn't know about (sometimes because it wasn't a 1 until less than a year ago). The best part of all this is not having to routinely ship Nightly-isms anymore. :slight_smile:

It's easy to look at that landslide and worry about the trend line, but it's also important to remember that the pool of important features is finite and shrinking. (Mine is, at least.) And with async/await having finally landed, I'm not aware of any such "huge" features left on the horizon. Compare how long it took for concept to land in C++ even given how vitally needed it was.

As for backwards compatibility, I recently had a dependency bitrot out from under me. It was a (barely) pre-1.0 crate, dating back to 2015, doing unseemly things with uninitialized memory. Other than that, the only times my old Rust code has broken have been when I took an old crate and put edition = "2018" in its Cargo.toml, after which I had to go around putting in a bunch of dyns and crate::s and taking out #[macro_use]s and extern crates. But I signed up for that by setting the edition to 2018 in the first place.


Rust releases are every 6 weeks :wink:

1 Like