Initial sketch: the next year of Rust

Author: aturon

_posts/2015-08-13-Next-year.md

@@ -0,0 +1,158 @@
+---
+layout: post
+title: "The next year of Rust"
+author: Nicholas Matsakis and Aaron Turon
+description: "Our vision for Rust in 2016."
+---
+
+It's now been 12 weeks since the release of Rust 1.0, and we'd like to take this
+opportunity to **talk a bit about what 1.0 meant in hindsight, and where Rust is
+going in the next year**.
+
+### The next year of Rust
+
+> We recently held the first-ever Rust conference, [RustCamp][rustcamp] 2015,
+which sold out with 160 attendees. It was amazing to see so much of the Rust
+community in person, and to see the vibe of our online spaces translate into a
+friendly and approachable meatspace event. The day opened with a keynote from
+Nicholas Matsakis and Aaron Turon laying out the core team's view of where we
+are and where we're headed. The
+[slides are available online](http://rustcamp.com/RustCampKeynote.pdf), but this
+post serves as the missing soundtrack.
+
+[rustcamp]: http://rustcamp.com/
+
+#### What 1.0 was about
+
+In hindsight, Rust 1.0 was about nailing down three key concerns: clarity,
+stability, and community. Stability, we've discussed quite a bit in
+[previous posts][deliverable]. And, of course, community has always been one of
+Rust's greatest strengths. But in the year leading up to 1.0 in particular, we
+introduced and refined the [RFC process][rfcs], culminating with
+[subteams][subteams] to manage RFCs in each particular area. Community-wide
+debate on RFCs was indispensable for delivering a quality 1.0 release.
+
+All of this refinement prior to 1.0 was in service of clarifying what Rust
+represents:
+
+- Memory safety without garbage collection
+- [Concurrency without data races][fearless]
+- [Abstraction without overhead][traits]
+- [Stability without stagnation][deliverable]
+
+Altogether, **Rust is exciting because it is empowering: you can hack without
+fear**. And you can do so in contexts you might not have before, dropping down
+from Ruby or Python, making your first foray into systems programming.
+
+That's Rust 1.0; what's next?
+
+[deliverable]: http://blog.rust-lang.org/2014/10/30/Stability.html
+[rfcs]: https://github.com/rust-lang/rfcs#when-you-need-to-follow-this-process
+[subteams]: https://github.com/rust-lang/rfcs/pull/1068
+[fearless]: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html
+[traits]: http://blog.rust-lang.org/2015/05/11/traits.html
+
+#### Where we go from here
+
+After much discussion within the core team and with the broader community, we've
+identified a number of improvements we'd like to make over the course of the
+next or so, falling into three broad categories:
+
+- Doubling down on infrastructure;
+- Zeroing in on gaps in key features;
+- Branching out into new places to use Rust.
+
+Let's look at some of the biggest plans in each of these categories.
+
+#### Doubling down: infrastructure investments
+
+**Crater**.
+
+**Incremental compilation**. [MIR][mir]
+
+[mir]: https://github.com/rust-lang/rfcs/pull/1211
+
+**IDE integration**.
+
+#### Zeroing in: closing key gaps in our features
+
+**Specialization**. The idea of zero-cost abstractions breaks down into two
+separate goals, as identified by Stroustrup:
+
+- What you don't use, you don't pay for.
+- What you do use, you couldn't hand code any better.
+
+Rust 1.0 has essentially achieved the first goal, both in terms of language
+features and the standard library. But it doesn't quite manage to achieve the
+second goal. Take the following trait, for example:
+
+~~~~rust
+pub trait Extend<A> {
+    fn extend<T>(&mut self, iterable: T) where T: IntoIterator<Item=A>;
+}
+~~~~
+
+The `Extend` trait provides a nice abstraction for insert data from any kind of
+iterator into a collection. But with traits today, that also means that each
+collection can provide only one implementation that works for *all* iterator
+types, which requires actually calling `.next()` repeatedly. In some cases, you
+could hand code it better, e.g. by just calling `memcpy`.
+
+To close this gap, we've proposed [specialization][specialization], allowing you
+to provide multiple, overlapping trait implementations as long as one is clearly
+more specific than the other. Aside from giving Rust a more complete toolkit for
+zero-cost abstraction, specialization also improves its story for code
+reuse. See [the RFC][specialization] for more details.
+
+[specialization]: https://github.com/rust-lang/rfcs/pull/1210
+
+**Borrow checker improvements**. The borrow checker is, in a way, the beating
+heart of Rust; it's the part of the compiler that lets us achieve memory safety
+without garbage collection, by catching use-after-free bugs and the like. But
+occasionally, the borrower checker also "catches" non-bugs, like the following
+pattern:
+
+~~~~rust
+match map.find(&key) {
+    Some(...) => { ... }
+    None => {
+        map.insert(key, new_value);
+    }
+}
+~~~~
+
+Code like the above snippet is perfectly fine, but the borrow checker struggles
+with it today because the `map` variable is borrowed for the entire body of the
+`match`, preventing it from being mutated by `insert`. We plan to address this
+shortcoming soon by refactoring the borrow checker to view code in terms of
+finer-grained ("non-lexical") regions -- a step made possible by the move to the
+MIR mentioned above.
+
+**Plugins**. There are some really neat things you can do in Rust today -- if
+you're willing to use the Nightly channel. For example, the [regex crate][regex]
+comes with macros that, at compile time, turn regular expressions directly into
+machine code to match them. Or the [rust-postgres-macros crage][postgres], which
+checks at compile time for valid SQL syntax. Crates like these and others make
+use of a highly-unstable compiler plugin system that currently exposes far too
+many compiler internals. We plan in the next couple of months to propose a new,
+robust design that closes these holes and provides good support for hygienic
+macro expansion as well.
+
+[regex]: https://github.com/rust-lang/regex
+[postgres]: https://github.com/sfackler/rust-postgres-macros
+
+#### Branching out: taking Rust to new places
+
+**Cross-compilation**.
+
+**Cargo install**. [RFC][cargoinstall]
+
+[cargoinstall]: https://github.com/rust-lang/rfcs/pull/1200
+
+**Tracing hooks**. One of the most promising way of using Rust is by "embedding"
+Rust code into systems written in higher-level languages like [Ruby][skylight]
+or Python. This embedding is usually done by giving the Rust code a C API, and
+works reasonably well when the target sports a "C friendly" memory management
+scheme like reference counting or conservative GC.
+
+[skylight]: http://blog.skylight.io/bending-the-curve-writing-safe-fast-native-gems-with-rust/