By contrast, for a language like Go, it's probably more practical to ship entire apps, rather than embedding in libraries, because there's significantly more overhead in terms of runtime system support.

However, to be clear, editions are primarily a marketing/communication/project management tool. They give us a way to try to bring together a number of threads of work into a coherent whole, with a high level of polish across the board (including docs and tooling), and then to present that work to the world with a clear story.

It's worth comparing this to the recent Firefox Quantum release, which was likewise a singled out release on the normal train process that brought together a number of important changes, marketing/communication, and a high level of polish.

> It's worth comparing this to the recent Firefox Quantum release

I don't think it's a fare comparison. Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is). And the changes are most drastic since early versions of FF. With Rust though, it's clearly improving every day, I don't see Q3 2018 as any sort of "quantum leap". At least for as long as it doesn't include the const generics :)

FWIW, this was part of the story from the beginning (https://github.com/rust-lang/rfcs/pull/2052)

> Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is).

They weren't just deprecated; they stopped working.

> I don't see Q3 2018 as any sort of "quantum leap"

For people following Rust closely, the Rust 2018 release won't be so special. But most people aren't keeping up with the details of new releases every six weeks; for them, we have an opportunity to take stock of what's changed over the last couple of years, explain the impact on idioms and how to transition code.

Remember that Rust is fairly unique in having a six week release cycle. Most other languages have a much slower release cycle, where every release is "major". Editions give us a way to pull together the rapid work we're doing into a coherent story.

From a management perspective, it's also a very useful way of focusing our effort as a community, to make sure all the pieces we've been working on are coming together into a polished whole on a clear timeline.

That is what editions are, though (though as I keep insufferably emphasizing, all breakage is opt-in). Can you be more specific about what you're afraid of?

> Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is).

You must not have been on any web forum discussing Firefox 57 if you don't remember the cacophonous, world-ending drama that deprecating legacy add-ons created. :P

I honestly can't think of a bigger breaking change that FF could have made.

Feel free to factor in that approximately five people use crates that I write, and most of them have bigger problems than Rust breakage. :)

It's not just targeted at C/C++ folks. The Rust team often hears from people who have been pulling their hair out trying to get a particular component written in a scripting language (Ruby, Python, JS) to go fast enough, which entails getting very intimate with the runtime systems for those languages. They're often surprised that they can instead write that core component in Rust, without giving up any developer productivity (or sometimes gaining it, compared to hand-optimizing their code), and get something much faster than what they were able to achieve in a scripting language.

There was a post just the other day on the Rust reddit telling this story: https://www.reddit.com/r/rust/comments/67m4eh/rust_day_two_a..., with a choice quote: "I feel like I discovered a programming super power or something. I mean I did expect it to be faster, but not this much faster this easily!" You can also check out the videos here: http://usehelix.com/resources

Rust also makes it much easier to write reliable software. The best example of this is with multithreaded programming (which is something you might reach for for speed), where Rust gives you guarantees not found in any other major language: you can know for sure that data is owned by one thread and not accessible by others, and the compiler will check this for you. You can know for sure that you only access lock-protected data while holding the lock. Rust will check thread safety for you, and more. You can read more about the concurrency benefits here: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

Relative to Go specifically, in addition to the reliability improvements, Rust supports a wider range of "systems" use cases. Unlike Go, it does not require a garbage collector or other runtime system, which makes it very easy to write small Rust components that can be used with a large script, or to write extremely performance-sensitive or low-level code like a browser or game engine, an operating system, or a bare-metal web server. One reason that Dropbox switched to Rust from Go for one of their core components is greater control over memory footprint, which allowed them to reduce their server memory needs by 4x, leading to significant financial savings.

The slogan I've been using for Rust personally is: Confident, Productive Systems Programming. You can write fast code. You can write low-level code. You can do it with high productivity, thanks to the work on modern tooling and ergonomics. But most importantly, you can do all of this fearlessly, because the Rust compiler has your back.

(0) Some types are eqtypes (akin to Rust types that implement the Eq trait, but managed entirely by the language, you can't define custom Eq impls).

(1) If a type constructor is an eqtype, then the result of applying it to an eqtype is an eqtype, but the result of applying it to a non-eqtype is a non-eqtype. For example, “list of ints” is an eqtype, but “list of functions” isn't.

Similarly, I propose that:

(0) Some types are copytypes (akin to Rust types that implement the Copy trait, again, managed entirely by the language).

(1) If a type constructor is a copytype, the result of applying it to a copytype is a copytype, but the result of applying it to a non-copytype is a non-copytype. For example, “list of ints” is a copytype, but “list of file objects” isn't.

Subtleties:

(0) If we have first-class functions, functions must be parameterized over whether they can be called more than once (akin to the distinction between FnOnce and Fn in Rust).

(1) When a value goes out of scope, its destructor is called. For copytypes, the destructor is guaranteed to be trivial, and can be optimized away. For “base non-copytypes” (e.g., file objects), the destructor is explicitly implemented by the programmer. For “derived non-copytypes” (e.g., lists of file objects, closures that have captured file objects), the destructor is automatically generated, and it does the obvious thing (destroy all file objects in the list, or captured by the closure).

The reason the impl is required is to ensure people write what they mean: it is backwards incompatible to go from Copy to non-Copy, so it would be unfortunate for a type to accidentally be Copy because an early version of the type happened to only contain Copy types. (The trait is really just a marker for "this type can be safely duplicated with memcpy".)

The Send and Sync traits are similar, and are in fact almost identical to eqtypes in that an explicit implementation is not required.

Yeah, I realized that, then deleted that part of my post.

> The reason the impl is required is to ensure people write what they mean: it is backwards incompatible to go from Copy to non-Copy, so it would be unfortunate for a type to accidentally be Copy because an early version of the type happened to only contain Copy types.

In my proposal, with an ML-style module system, you can define an abstract non-copytype whose internal representation is a copytype, just like in Standard ML you can define an abstract non-eqtype whose internal representation is an eqtype.

I've updated the RFC to clarify this; thanks for the comment!