Rust 1.12 release announcement

_posts/2016-09-29-Rust-1.12.md

@@ -31,10 +31,10 @@ what you think of them:
 ![A new borrow-check error](/images/2016-09-Rust-1.12/borrowck-error.png)
 
 The largest internal change in this release is moving to a new compiler backend
-based on the new Rust [MIR]. While this feature does not result in any new
-user-visible features, it paves the way for a number of future compiler
-optimizations, and for some codebases it already results in improvements to
-compile times and reductions in code size.
+based on the new Rust [MIR]. While this feature does not result in anything
+user-visible, it paves the way for a number of future compiler optimizations,
+and for some codebases it already results in improvements to compile times and
+reductions in code size.
 
 [previously talked]: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html
 [volunteer effort]: https://github.com/rust-lang/rust/issues/35233
@@ -54,17 +54,17 @@ declaration, you would see an error like the one below:
 error](/images/2016-09-Rust-1.12/old-mismatched-trait-error.png)
 
 In the new error format we represent the error by instead showing the points in
-the code that matter the most. Here the relevant line in the trait declaration,
-and the relevant line in the implementation, using labels to describe why they
-don't match:
+the code that matter the most. Here is the relevant line in the trait
+declaration, and the relevant line in the implementation, using labels to
+describe why they don't match:
 
 ![A new mismatched trait
 error](/images/2016-09-Rust-1.12/mismatched-trait-error.png)
 
-Initially, this error design was built to aid borrow-checking errors, but we
-found, like the error above, the format can be broadly applied to a wide variety
-of errors. If you would like to learn more about the design, check out the
-[previous blog post on the subject][err].
+Initially, this error design was built to aid in understanding borrow-checking
+errors, but we found, as with the error above, the format can be broadly
+applied to a wide variety of errors. If you would like to learn more about the
+design, check out the [previous blog post on the subject][err].
 
 [err]: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html
 
@@ -86,7 +86,7 @@ effort.
 #### MIR code generation
 
 The new Rust "mid-level IR", usually called "MIR", gives the compiler a simpler
-way to think about Rust code than it's previous way of operating entirely on the
+way to think about Rust code than its previous way of operating entirely on the
 Rust abstract syntax tree. It makes analysis and optimizations possible that
 have historically been difficult to implement correctly. The first of many
 upcoming changes to the compiler enabled by MIR is a rewrite of the pass that
@@ -95,17 +95,6 @@ effort the MIR-based backend has proved itself ready for prime-time.
 
 TODO: Improve code complexity: size of old trans vs size of new trans.
 
-While for the most part this new backend is simply laying the groundwork for
-future improvements, this release does include one long-awaited refinement to
-the run-time representation of Rust types that results in both compile-time wins
-and runtime wins: the removal of "drop flags", AKA "non-zeroing drop", as
-specified in [RFC 320].
-
-To maintain the semantics of Rust's `Drop` implementation, we always need to
-check whether a type must be dropped when it goes out of scope. Historically,
-this has been done by adding a special flag to all types that implement `Drop`,
-but this resulted in significant extra memory being used at runtime.
-
 MIR exposes perfect information about the program's control flow, so the
 compiler knows exactly whether types are moved or not. This means that it knows
 statically whether or not the value's destructor needs to be run. In cases where
@@ -117,12 +106,12 @@ less bloat at runtime.
 The improvements in compile times of some workloads due to this change alone are
 significant:
 
-|               | 1.11   | 1.12  | compile time |
-|---------------|--------|-------|--------------|
-| inflate-0.1.0 | 10.17s | 4.32s | 2.35x faster |
-| hyper-0.5.0   | 24.03s | 5.23s | 4.58x faster |
-| hellworld     | 0.17s  | 0.14s | 1.20x faster |
-| regex 0.1.30  | 9.63s  | 2.39s | 4.03x faster |
+|               | 1.11   | 1.12  | compile time  |
+|---------------|--------|-------|---------------|
+| inflate-0.1.0 | 10.17s | 4.32s | 2.35x faster  |
+| hyper-0.5.0   | 24.03s | 5.23s | 4.58x faster  |
+| helloworld     | 0.17s  | 0.14s | 1.20x faster |
+| regex 0.1.30  | 9.63s  | 2.39s | 4.03x faster  |
 
 It is worth remembering that not all workloads may see this large of an
 improvement: it depends on a large number of factors.
@@ -131,15 +120,6 @@ TODO: Future improvements.
 
 TODO: non-zeroing drop PR https://github.com/rust-lang/rust/pull/33622
 
-Compile times:
-
-|               | 1.11   | 1.12  | % change |
-|---------------|--------|-------|----------|
-| inflate-0.1.0 | 10.17s | 4.32s | -57.5%   |
-| hyper.0.5.0   | 24.03s | 5.23s | -78.2%   |
-| helloworld    | 0.17s  | 0.14s | -16.4%   |
-| regex.0.1.30  | 9.63s  | 2.39s | -75.2%   |
-
 [Memory usage](https://en.wikipedia.org/wiki/Resident_set_size):
 
 |               | 1.11  | 1.12  | % of original size |