Merge pull request #1 from nikomatsakis/aturon-next-year

first draft of mising sections

Author: aturon

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

@@ -66,13 +66,71 @@ Let's look at some of the biggest plans in each of these categories.
 
 #### Doubling down: infrastructure investments
 
-**Crater**.
-
-**Incremental compilation**. [MIR][mir]
+**Crater**. One of our big goals with Rust is that upgrades between
+versions should be "hassle-free". An important part of this story is
+detecting compiler bugs that cause code to stop working. Naturally,
+the compiler has its own large test suite, but that is only a small
+fraction of the code that's out there "in the wild". [Crater] is a
+tool that aims to close that gap by testing the compiler against all
+the packages found in [crates.io], giving us a much better idea
+whether any code has stopped compiling recently.
+
+We've been using the current version of crater for some time. For
+example, we regularly compare the nightly release against the latest
+stable build. We also use crater to check in-progress branches and
+estimate the impact of a change. 
+
+Interestingly, we have often found that when code stops compiling,
+it's not because of a bug in the compiler. Rather, it's because we
+*fixed* a bug, and that code happened to be relying on the older
+behavior. Even in those cases, using crater lets us improve the
+experience. For example, for changes that affect a lot of projects,
+we've often chosen to phase in the change gradually. In such cases, we
+issue one release where users get warnings, and only start issuing
+errors on the next release, giving people time to migrate their code.
+
+Over the next year or so, we plan to improve crater in numerous ways.
+For example, we'd like to extend the coverage to other platforms (not
+just linux). We'd also like to make it smoother to use, and include
+code from other sources beyond [crates.io].
+
+[Crater]: https://github.com/brson/taskcluster-crater
+
+**Incremental compilation**. Rust has always had a "crate-wide"
+compilation model. This means that the Rust compiler reads in all of
+the source files in your crate at once. These are type-checked and
+then given to LLVM for optimization. This approach is really great for
+doing deep optimization, because it gives LLVM full access to the
+entire set of code, allowing for more better inlining, more precise
+analysis, and so forth. However, it can mean that turnaround is slow:
+even if you only edit one function, we will recompile everything. When
+projects get large, this can be a burden. 
+
+The incremental compilation project aims to change this by having the
+Rust compiler save intermediate by-products and re-use them. This way,
+when you're debugging a problem, or tweaking a code path, you only
+have to recompile those things that you have changed, which should
+make the "edit-compile-test" cycle much faster.
+
+Part of this project is restructuring the compiler to introduce a new
+intermediate representation, which we call [MIR][mir]. MIR is a kind
+of simplified form of Rust code that hides a lot of the details from
+full Rust. This is a crucial enabler for language changes like
+non-lexical lifetimes (discussing in the next section).
 
 [mir]: https://github.com/rust-lang/rfcs/pull/1211
 
-**IDE integration**.
+**IDE integration**. Top-notch IDE support can help to make Rust even
+more productive. Up until now, pioneering projects like
+[Racer][racer], [Visual Rust][visualrust], and [Rust DT][rustdt] have
+been working largely without compiler support. We intend to extend the
+compiler to permit deeper integration; the plan is to focus initially
+on two IDEs, and then grow from there.
+
+[syntax highlighting]: https://github.com/rust-lang/rust/blob/master/src/etc/CONFIGS.md
+[racer]: https://github.com/phildawes/racer
+[visualrust]: https://github.com/PistonDevelopers/VisualRust
+[rustdt]: https://github.com/RustDT/RustDT
 
 #### Zeroing in: closing key gaps in our features
 
@@ -117,7 +175,7 @@ match map.find(&key) {
     Some(...) => { ... }
     None => {
         map.insert(key, new_value);
-    }
+   }
 }
 ~~~~
 
@@ -143,16 +201,49 @@ macro expansion as well.
 
 #### 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.
+**Cross-compilation**. While cross-compiling with Rust is possible
+today, it involves a lot of manual configuration. We're shooting to
+make it a streamlined, simple process. The idea is that compiling Rust code
+for another target should be easy:
+
+1. Download a precompiled version of `libstd` for the target in question,
+   if you don't already have it.
+2. Execute `cargo build --target=foo`.
+3. There is no step 3.
+
+**Cargo install**. Cargo and [crates.io] is a really great tool for
+distributing libaries, but it lacks any means to install executables.
+[RFC 1200] describes a simple addition to cargo, the `cargo install`
+command.  Much like the conventional `make install`, `cargo install`
+will place an executable in your path so that you can run it. This can
+serve as a simple distribution channel, and is particularly useful for
+people writing tools that target Rust developers (who are likely to be
+familiar with running cargo).
+
+[RFC 1200]: 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. However, integrating with an environment
+that uses a more advanced GC can be quite challenging. Perhaps the
+most prominent examples are JavaScript engines like V8 (used by
+[node.js]) and SpiderMonkey (used by [Firefox] and
+[Servo]). Integrating with those engines requires very careful coding
+to ensure that all objects are properly rooted; small mistakes can
+easily lead to crashes. These are precisely the kind of memory
+management problems that Rust is intended to eliminate. To address
+this gap, we plan to extend the compiler with the ability to generate
+"trace hooks". These hooks can be used by a GC to sweep the stack and
+identify roots, making it possible to write code that integrates with
+advanced VMs smoothly and easily. Naturally, the design will respect
+Rust's "pay for what you use" policy, so that code which does not
+integrate with a GC is unaffected.
 
 [skylight]: http://blog.skylight.io/bending-the-curve-writing-safe-fast-native-gems-with-rust/
+[crates.io]: https://crates.io
+[nodejs]: https://nodejs.org/
+[Servo]: https://github.com/servo/servo
+[Firefox]: http://firefox.com/