1. 22

Performance wins, incremental compilation, and the Rust 2018 Roadmap and Epoch!


  2. 2

    Is there a good resource for understanding Epochs as overlays to the release/versioning system in Rust (if that’s even the right way to think about them)? I use and follow Rust development but haven’t really wrapped my head around the significance of Epochs.

    1. 6

      Epochs are a way for the Rust team to make breaking changes to the syntax of Rust. For example, reserving new keywords, turning warn-by-default checks into error-by-default, that kind of thing.

      Importantly, crates designed for different epochs can be used together, so a Rust epoch won’t fracture the ecosystem like the infamous Python 2/3 split. Even if you want to call a function in an old library whose name is a reserved word in the new epoch, Rust provides a “raw identifier” syntax so you can use anything (within reason) as an identifier.

      More pragmatically, epochs are an excuse for more publicity. With a release every six weeks, you rarely get more than one or two new features at a time, which isn’t worth making a fuss about, so people outside the Rust community rarely hear about all the stuff that’s going on. An epoch is an excuse to list all the features of the past year or two and show people just how much progress has been made.

      1. 1

        Understanding this as presented, then, it is a breaking change that exceeds the threshold for even major version changes.

        Does that mean an Epoch change will always occur simultaneously with a major version change? And that an earlier Epoch is always incompatible with a later major version?

        I think this has been the confusing part to me.

        1. 9

          No, because you have to explicitly opt in to the new epoch.

          Code on newer epochs using your code does not break.

          People compiling your code with rustc or cargo do not break (rustc and cargo continue to use the same epoch to compile your code)

          The only time your code breaks is when you explicitly do rustc yourcode.rs --epoch=2018 or cargo build after modifying the epoch key in Cargo.toml.

          Which you’ll only do when upgrading to the epoch.

          Rust does not deprecate programming within the old epoch, so it continues to work. Five epochs from now the “2015 epoch” and “2018 epoch” should still work with the latest compiler.

          Also, Rust does not automatically choose the latest epoch for you: it defaults to the 2015 epoch when unspecified. The only time it uses the latest epoch is when you create a new project with cargo.

          Does this make sense?

          1. 4

            it is a breaking change that exceeds the threshold for even major version changes.

            Not really. The breaking changes we’re talking about are “turn some warnings into errors” and “add new keywords”. Fundamentally, the changes possible are very limited. It’s a core constraint of epochs. Also, as was said elsewhere, your code shouldn’t break without an explicit action on your part. And the whole thing is interoperable.

            The closest analogy is the C++ and Java systems. Each new release does technically break some things, but they’re very minor, and so to most people they’re languages that “never break things.”

            1. 2

              Major version changes would include things like removing language features, or adding a mandatory garbage collecting runtime, or anything else that would prevent older code and newer code from working together.

              An epoch explicitly cannot introduce such incompatible changes; it must always be possible for old-epoch crates and new-epoch crates to be used together.. It might not be possible to copy/paste code between them, i.e. they may not be source compatible, but they should compile down to the same ABI, effectively.

              This is not exactly the same thing as ABI stability; a crate compiled by an old-epoch compiler and a crate compiled by a new-epoch compiler probably won’t be compatible. However, the Rust project has promised that every 1.x Rust compiler will always support every previous epoch, so you can take your new-epoch compiler, compile one crate in old-epoch mode and another crate in new-epoch mode, and then they’ll be compatible.

          2. 4

            The canonical text is https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md . It should explain it reasonably well, if you’re the kind of person who follows Rust development.

            That said, we haven’t actually done one yet, so it’s kinda hard to point to an example, it’s all theory at the moment. They also may not even be called “epochs” when we actually ship one. The name is… okay. I like it for its bad qualities, which probably means we should change it :p