1. 19
  1.  

  2. 5

    This definitely sounds great; I like the async/await paradigm a lot.

    Now, let me try to phrase this in a way where I won’t get downvoted:

    Is Rust going to “stabilize” at some point? Just looking at it as an outsider, I feel like Rust moves and changes very quickly, especially for non-major-version changes.

    One of the reasons that I haven’t gotten more into Rust (which seems to tick a lot of my boxes) is that I feel (rightly or wrongly, correct me please!) that the language is constantly in flux and there’s no point in learning how to write “idiomatic Rust” because what’s “idiomatic” won’t be in six months.

    Looking at the release history, it seems like every version has either a list of “Breaking Changes” or “Compatibility Notes” or both.

    Again, that’s just what I get from seeing release notes every so often with seemingly major features added or deprecated every so often. Someone correct me if I’m wrong.

    1. 5

      async/await is a bit of an exception. It’s probably the first change since 2015 (1.0 release) that actually changes how a lot of Rust code will look and work. The rest of changes was pretty minor and incremental.

      From insider perspective, Rust fills in gaps that were in the MVP and adds tiny amounts of syntax sugar. You couldn’t initialize many global variables. Now you can (const fn). You couldn’t call certain methods in match arms, now it just works (moves in match guards). The compiler was very very pedantic about order of variable definitions, but now it’s less (smarter “NLL” borrow checker). The compiler was very pedantic about use of & and ref in patterns, but these have been made optional, because they were annoying, and compiler knows what you mean without them. I consider this bugfixes/polishing of the language, but not really changes to what Rust is.

      In terms of breaking changes Rust is less of a hassle than GCC updates.

      1. 4

        Everything on stable rust is stabilised. Stabilisation is a commitment that code written against that feature won’t break in the future. Code written again Rust 1.0 should still compile fine with Rust 1.39.0, although it may emit warnings now. The project takes this commitment very seriously.

        The one exception to this guarantee is bugs/unsoundness. If these things are discovered they will be fixed, possibly breaking code. As pointed out in the post this is typically done in a phased approach and doesn’t actually impact that much code.

        There are regular “crater runs” Done that build every crate on crates.io to measure the impact of a change/ensure that it does not break things.

        1. 3

          Everything on stable rust is stabilised.

          I phrased it poorly. I realize that these features are “in stable”…what I meant was “are they going to stop or slow down on pushing new major features into stable so that I can say I write in ‘Rust’ and not ‘Rust 1.32.0’”?

          In other words, it’s great that my 1.0 code will compile on 1.39.0, but I feel like 1.39 has a lot of differences from 1.0 and from many versions in between. I start to learn 1.39, and then 1.40 comes out and there’s a whole lot more to learn, and when I get comfortable with 1.40, 1.41 comes out with more changes, etc…

          I’m not saying that’s what’s happening, I’m saying that’s the perception I get from the release notes. I’m happy to be proven wrong.

          (PS> I realize Python is sorta-kinda guilty of this too, but I feel like maybe to not the same degree. Maybe I’m just old and set in my ways, I don’t know.)

          1. 4

            In other words, it’s great that my 1.0 code will compile on 1.39.0, but I feel like 1.39 has a lot of differences from 1.0 and from many versions in between.

            The largest changes since 1.0 were in the Rust 2018 edition, I feel like there haven’t been any big changes since then (until async + await if that affects you). Also, 1.0 code may look a bit strange with its use of the try! macro, etc. But I wouldn’t say that if you wrote Rust 1.0 code now it would be unidiomatic.

            At any rate, if you don’t like churn, it guess it is completely fine to write against Rust editions. So, write what was Rust 2018 until the next edition is out ;). I have been doing that is much as possible to support older Rust compiler versions.

        2. 2

          I don’t think there are a great number of such changes scheduled, other than non-lexical lifetimes. I’m an actively-monitoring keen outsider, rather than a daily user though, so take it with a grain of salt.

          1. 3

            other than non-lexical lifetimes

            That’s been shipped, for both editions, since July