[rust-dev] Thoughts on the Rust Roadmap
pwalton at mozilla.com
Mon Dec 30 09:35:09 PST 2013
We plan on not breaking code after Rust 1.0, except for gated features. That said, we reserve the right to change things in potentially breaking ways if type/memory unsoundness is discovered. We also might change small, inconsequential things if we're reasonably sure nobody is relying on them--the bar for this is high, however.
Libraries will follow a set of stability level guarantees that vary on a module-by-module basis. Stability encompasses both API level stability and semantic stability: if the semantics change in a way that is likely to break code, we'll introduce a new API instead of modifying a stable one.
There will be plenty of new features added (e.g. unboxed closures, higher kinded type parameters), and we discuss them a lot these days to make sure we don't close them off.
We haven't discussed it, but I assume Rust 2.0 might break things. That will presumably be a long way off though.
"Gábor Lehel" <glaebhoerl at gmail.com> wrote:
>It would be helpful to know what the (rough) plan is for after 1.0. A
>series of 1.x releases and later 2.0, or just 2.0? At what kind of time
>scales? What kind of changes will be appropriate for each? (i.e.
>features, bugfixes, compatibility breaks of various forms in various
>How is Rust going to feel about the prospect of backwards-incompatible
>changes after 1.0? Like C++: never ever break anything ever ever?
>On Mon, Dec 30, 2013 at 5:29 PM, Patrick Walton
><pcwalton at mozilla.com>wrote:
>> On 12/30/13 5:00 AM, Armin Ronacher wrote:
>>> But there is so much more work needed. Not just because the
>>> lacking things that are needed, but because many users of the
>>> are not sure yet how to use it.
>> Documentation is independent of freezing the language definition.
>> The compiler and the standard library use widely different patterns
>>> so do libraries written by other people.
>> IMO, the compiler doesn't need to be updated to modern Rust before
>> (`javac` is still not updated to modern Java standards, for example.)
>> standard library does, however.
>> There are half a dozen ways to
>>> deal with errors now, there are different patterns of how to deal
>>> Options and Results.
>> These need to be cleaned up before 1.0. Conditions in particular need
>> be removed.
>> There are vastly different ways to design whole
>>> APIs, how to deal with the traits and so forth.
>> We'll standardize on something before 1.0. The traits need to be
>> redesigned in general.
>> There are different
>>> patterns to interface with native libraries, different patterns to
>>> interface with task local data etc.
>> Are you referencing RAII versus `with_foo` style methods? The latter
>> deprecated and should be removed before 1.0.
>> The introduction of external iterators (which I found the most
>>> change of the language) has shown a whole new area of shortcomings
>>> the current feature set (lack decltype when returning composed
>>> for instance,
>> This is the first time I've heard of this as a missing feature, and
>> opposed. This would make typechecking significantly more complex.
>> non sendable closures etc.).
>> Is `proc` not sufficient? We could prioritize adding unboxed
>> since they're backwards compatible as far as I know, I don't see a
>> need to add them before 1.0.
>> Not only did it show
>>> shortcomings in lacking features, it also put some emphasis on new
>>> patterns that are not widely deployed in the stdlib yet.
>> We need to add them before 1.0, but I personally don't see any major
>> missing language features that we absolutely need to add, except
>> are already on the roadmap.
>> I really hope there is left enough time to actually continue
>>> the language and libraries before freezing anything. Especially now
>>> that the split into libnative and libgreen is happening it will be
>>> important to stay flexible for adjusting the design of the standard
>>> library so that we don't end up with two vastly different ways to do
>> We aren't going to freeze the entire standard library for all time
>> 1.0. Instead there will be "stability levels" like node.js (something
>> "frozen", "stabilizing", "unstable", "experimental"). I don't
>> that all of libstd will be frozen before 1.0. Some modules will, and
>> modules will not.
>> As it stands right now, there
>>> are too many things that make Rust still frustrating because you
>>> yourself into a corner.
>> It'd be best to file specific issues here. I'm sympathetic to wanting
>> adding more features if they're necessary, but none of the *specific*
>> things mentioned in this post seem like blockers to me.
>> In general I understand the concern, but there are also a huge number
>> people who just want the language to stabilize so that they can use
>> production. The window for relevance is finite and we've been
>> language for a *long* time at this point.
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev