"Epoch" vs "era"

[aturon]

In writing up the 2018 roadmap blog post draft, some of the writing led me to consider “era” as an alternative to “epoch”. While they’re considered synonyms, they have a distinct flavor for native speakers:

• Era feels a bit less like a “strong break”, and more like the natural passage of time and evolution. In particular, it feels natural to talk about the “Rust 2015 era” when referring to how code was written shortly after 1.0.

In addition, era doesn’t suffer from the pronounciation issues we’ve hit with “epoch”, and overall has a friendly and more approachable flavor.

The blog post is now expected to go out on Monday, and we need to settle the question before then. At the moment, the core team pretty strongly leans toward “era”, and anecdotal data from folks not deeply steeped in the Rust community suggests that “era” feels more approachable. OTOH, at least at the moment, “epoch” is winning @carols10cents’s highly scientific Twitter poll.

---

The core team is interested in getting feedback before Monday. Please do not use the thread to re-litigate the concept of epochs or the versioning strategy, but stay focused on the immediate bikeshed.

• epoch
• era
• other (comment below)

Show results

[zackw]

Outside of geology, I think “epoch” is more often used to refer to a single point in time, whereas “era” is always an extended period of time. So that would be an argument for “era”.

I can’t resist proposing “edition” as a third alternative. The standards for standardized languages have editions, identified by year of publication.

[bstrie]

Era does manage to sound less like breakage and also less like jargon. I’m mildly in favor.

[Luthaf]

Era sound a bit better as a non native english speaker. It is not ideal as it feels a bit ancient (in french, the corresponding word is). But epoch feels completely weird and has no meaning for me.

[phaylon]

I’ve selected epoch because “Back in Rust’s 2015 era” doesn’t sound like I’m talking about a specific language version. Compare:

• In Rust’s 2018 era the syntax for trait objects was changed.
• In Rust’s 2018 epoch the syntax for trait objects was changed.

[sunjay]

Seeing as how the Twitter poll has almost completely opposite results, I think your written justification for Era may have primed the people voting here.

[leonardo]

In software often people use the words “version”, revisions, etc, So I like “Rust version 1” for the first era, “Rust version 2” for the second, etc. So now we’re in Rust V. 1.24.1, later we’ll be in Rust V 2.0, etc

[steveklabnik]

later we’ll be in Rust V 2.0

Part of the epoch RFC is that we’ll never do a 2.0.

[leonardo]

What’s the real intrinsic meaning of Rust V. 2.0 for you? And why isn’t it fit for the second era/epoch of Rust?

[jethrogb]

I think we’ll mostly just talk about “Rust 2015” or “Rust 2018”, so the exact field name used to represent the year doesn’t matter much to me.

[aturon]

I think your written justification for Era may have primed the people voting here

Totally unintentional

(That said I think the twitter poll provided too little context to be meaningful)

[aturon]

What’s the real intrinsic meaning of Rust V. 2.0 for you? And why isn’t it fit for the second era/epoch of Rust?

To re-iterate: we’re not going to re-raise the question of versioning scheme (years versus numeric versions), which was discussed in enormous length in the epochs RFC. The question is just how to refer to the scheme we arrived at.

[gilescope]

It’s end of an epoc.

[withoutboats]

I agree with @jethrogb that eventually we’ll move away from talking about this concept at all, and just talk about the years of the epoch/era/whatever releases - Rust 2015, Rust 2019. As much as possible I’d like to avoid this terminology showing up in the interface of rustc and cargo.

So whatever terminology we choose, we should prioritize the messaging we want to send now, while we’re explaining the concept, rather than worrying about the long term implications of what terminology we choose. Eventually this will just be a second nature part of how Rust development works (unless it goes unexpectedly terribly, in which case it will never happen again, so same outcome ).

I’ve definitely seen attempts to explain this to outside users which stumble over the current terminology. What we want to get across is that this isn’t a breaking change, and even after saying that I see responses like “so an epoch is a breaking change that’s even more breaking than 2.0,” the exact opposite of our intent.

[withoutboats]

I’d also add that I like “edition” the best of the three names here, as it seems less like a reach for a metaphor. I also think we should heavily lean on the idea that what we’re doing is fundamentally the same as C++XX or Java 1.X.

[jntrnr]

Seconded. “edition” feels like the most friendly/readable of the three.

[jaroslaw-weber]

Cycle, Aeon, Period, Release, Version, Stage, Season, Generation

[nematsakis]

It’s worth noting that Ecmascript uses “edition” as well, though technically “edition” refers to the edition of the specification which defines a language named something like “Ecmascript 2016”.

The proposed Rust epoch concept shares much with Ecmascript editions, in that the editions define a set of generally backwards-compatible features that arrive in browsers continuously. If a change is not backwards compatible, you have to opt in (for example with strict mode).

[tafia]

To me “edition” looks like a particular point of time while “epoch” and “era” are wider. In terms of duration, I feel like era > epoch > edition.

So we could have rust pre 1.0 era, rust post 1.0 era and several epochs in each era (futures, async, procedural macros, rustc_serialize/serde etc …).

[aturon]

To me “edition” looks like a particular point of time while “epoch” and “era” are wider

I feel the same. In particular, “edition” risks over-emphasizing the specific release that initiates a new, er, epoch.

OTOH, if for most people it has a much more intuitive connotation around backwards compatibility it’s worth considering.