Merge pull request #1 from aturon/1.9-edits

1.9 edits

Author: steveklabnik

_posts/2016-05-26-Rust-1.9.md

@@ -16,42 +16,10 @@ About 1400 patches were landed in this release.
 
 ### What's in 1.9 stable
 
-Rust 1.9 contains some exciting new things!
+#### Controlled unwinding
 
-First up, a new attribute for library authors: `#[deprecated]`. Authors of
-libraries can now tag items with this attribute, and users of their crate
-will see a warning when it is used. This new feature was defined in [RFC 1270].
-
-[RFC 1270]: https://github.com/rust-lang/rfcs/blob/master/text/1270-deprecation.md
-
-We now publishes std binaries for the `mips-unknown-linux-musl`,
-`mipsel-unknown-linux-musl`, and `i586-pc-windows-msvc` targets.
-
-[The time complexity of comparing variables for equivalence][compare] during
-type unification is reduced from O(n!) to O(n). What does this mean? Certain
-kinds of code compiles much, much faster.
-
-[compare]: https://github.com/rust-lang/rust/pull/32062
-
-Strings are a very common type, and implement a lot of different traits.
-Specifically, when converting between `&str` and `String`, you have many
-options. Rustaceans used these two the most:
-
-```rust
-let s = "some string".to_string();
-let s = "some string".to_owned();
-```
-
-The former is the official convention, but it was discovered that it's not
-as fast as the second method. For a long time, it was not possible to improve
-this situation, however, a new language feature has landed on nightly and made
-this possible. [`libstd` now uses this internally][str] to make the two equivalent.
-
-[str]: https://github.com/rust-lang/rust/pull/32586
-
-Finally, this feature is technically a library change, but it's worth
-mentioning here as well. The `std::panic` module is being stabilized. This
-allows panics to be caught:
+The biggest shift in Rust 1.9 is the stabilization of the `std::panic` module,
+which includes methods for halting the unwinding process started by a panic:
 
 ```rust
 use std::panic;
@@ -67,83 +35,161 @@ let result = panic::catch_unwind(|| {
 assert!(result.is_err());
 ```
 
-This behavior was defined in [RFC 1236].
+This new API was defined in [RFC 1236].
 
 [`std::panic`]: http://doc.rust-lang.org/stable/std/panic/index.html
 [RFC 1236]: https://github.com/rust-lang/rfcs/pull/1236
 
-Historically, this has not been possible in Rust: panics are always
-unrecoverable. And in practice, this is still how they should be used. While
-the current implementation of `panic!` does unwinding, in a future release,
-crates will be able to choose a different implementation, namely, that
-`panic!` causes an abort, rather than unwind. Given that panics are for
-non-recoverable errors only, this is a valid implementation.
+In general, Rust distinguishes between two ways that an operation can fail:
+
+- Due to an *expected problem*, like a file not being found.
+- Due to an *unexpected problem*, like an index being out of bounds for an array.
+
+Expected problems usually arise from conditions that are outside of your
+control; robust code should be prepared for anything its environment might throw
+at it. In Rust, expected problems are handled via [the `Result` type][result],
+which allows a function to return information about the problem to its caller,
+which can then handle the error in a fine-grained way.
+
+[result]: http://static.rust-lang.org/doc/master/std/result/index.html
+
+Unexpected problems are *bugs*: they arise due to a contract or assertion being
+violated. Since they are unexpected, it doesn't make sense to handle them in a
+fine-grained way. Instead, Rust employs a "fail fast" approach by *panicking*,
+which by default unwinds the stack (running destructors but no other code) of
+the thread which discovered the error. Other threads continue running, but will
+discover the panic any time they try to communicate with the panicked thread
+(whether through channels or shared memory). Panics thus abort execution up to
+some "isolation boundary", with code on the other side of the boundary still
+able to run, and perhaps to "recover" from the panic in some very coarse-grained
+way. A server, for example, does not necessarily need to go down just because of
+an assertion failure in one of its threads.
 
-If panics are for non-recoverable errors, why provide an interface for
-recovering from them? There are two big use-cases here:
+The new `catch_unwind` API offers a way to introduce new isolation boundaries
+*within a thread*. There are a couple of key motivating examples:
 
 * Embedding Rust in other languages
 * Abstractions that manage threads
 
 For the first case, unwinding across a language boundary is undefined behavior,
-and often leads to segfaults in practice. This means that when embedding Rust
-inside of other languages, you must avoid any code that can possibly panic, or
-rely on the (still unstable and only recently landed) 'abort' implementation of
-panic. Allowing panics to be caught at the language boundary provides more
-options in this case: an issue in Rust can return an error, rather than aborting
-the entire process. This is very important for many use-cases of embedding Rust;
-aborting is not always an acceptable option.
-
-In the second, consider a threadpool library. If a thread panics, it's
-reasonable for the pool to not want to abort, but instead report the error,
-and, depending on the details, possibly even restart the thread, in an
-Erlang-style model. Recovering from these kinds of errors is very useful.
-
-This change had a lot of discussion and thought put into it, by a large group
-of people. A significant worry about this change is that people may use it to
-try and emulate exceptions, which is not the intention of this functionality.
-However, the use-cases for this feature are legitimate, and there are two
-reasons we believe that this will not happen, generally:
-
-* Rust already has a very strong culture of using `Result<T, E>` and `panic!`
-  appropriately, and a new function will not change this culture overnight.
-* A significant part of Rust's userbase desires the abort implementation of
-  panic, and libraries will need to work with both implementations.
+and often leads to segfaults in practice. Allowing panics to be caught means
+that you can safely expose Rust code via a C API, and translate unwinding into
+an error on the C side.
 
-See the [detailed release notes][notes] for more.
+For the second case, consider a threadpool library. If a thread in the pool
+panics, you generally don't want to kill the thread itself, but rather catch the
+panic and communicate it to the client of the pool. The `catch_unwind` API is
+paired with `resume_unwind`, which can then be used to restart the panicking
+process on the client of the pool, where it belongs.
+
+In both cases, you're introducing a new isolation boundary within a thread, and
+then translating the panic into some other form of error elsewhere.
+
+A final point: why `catch_unwind` rather than `catch_panic`? We are
+[in the process][abort] of adding an additional strategy for panics: aborting
+the entire process (possibly after running a general [hook]). For some
+applications, this is the most reasonable way to deal with a programmer error,
+and avoiding unwinding can have performance and code size wins.
+
+[hook]: https://github.com/rust-lang/rfcs/pull/1328
+[abort]: https://github.com/rust-lang/rfcs/pull/1513
+
+#### Deprecation warnings
+
+We introduced a new attribute for library authors: `#[deprecated]`. This attribute
+allows you to tag an API with a deprecation warning, which users of their crate
+will receive whenever they use the API, directing them to a replacement API.
+Deprecation warnings have long been a part of the standard library, but thanks
+to [RFC 1270] they're now usable ecosystem-wide.
+
+[RFC 1270]: https://github.com/rust-lang/rfcs/blob/master/text/1270-deprecation.md
+
+#### New targets
+
+We now publish standard library binaries for several new targets:
+
+- `mips-unknown-linux-musl`,
+- `mipsel-unknown-linux-musl`, and
+- `i586-pc-windows-msvc`.
+
+The first two targets are particularly interesting from a cross-compilation
+perspective; see the [recent blog post on `rustup`][rustup] for more details.
+
+[rustup]: http://blog.rust-lang.org/2016/05/13/rustup.html
+
+#### Compile time improvements
+
+[The time complexity of comparing variables for equivalence][compare] during
+type unification is reduced from O(n!) to O(n). As a result, some programming
+patterns compile much, much more quickly.
+
+[compare]: https://github.com/rust-lang/rust/pull/32062
+
+#### Rolling out use of specialization
+
+This release sees some of the first use of [specialization] within the standard
+library. Specialization, which is currently available only on [nightly], allows
+generic code to automatically be specialized based on more specific type
+information.
+
+One example where this comes up in the standard library: conversion from a
+string slice (`&str`) to an owned `String`. One method, `to_string`, comes from
+a generic API which was previously relatively slow, while the custom `to_owned`
+implementation provided better performance. Using specialization, these two
+functions are [now equivalent].
+
+With this simple test of specialization under our belt, we have more performance
+improvements on the way in upcoming releases.
+
+[specialization]: https://github.com/rust-lang/rfcs/pull/1210
+[nightly]: http://blog.rust-lang.org/2014/10/30/Stability.html
+[now equivalent]: https://github.com/rust-lang/rust/pull/32586
 
 #### Library stabilizations
 
-About 80 library functions and methods are now stable in 1.8. Lots of stuff!
-The most major is the `std::panic` module, described in the previous section,
-but there's a lot more too:
+About 80 library functions and methods are now stable in 1.9.  The most major is
+the `std::panic` module, described earlier, but there's a lot more too:
+
+**Networking**
+
+* `TcpStream`, `TcpListener`, and `UdpSocket` gained a number of methods for
+  configuring the connection.
+* `SocketAddr` and its variants gained `set_ip()` and `set_port()` conveniences.
+
+**Collections**
+
+* `BTreeSet` and `HashSet` gained the `take()`, `replace()`, and `get()`
+  methods, which make it possible to recover ownership of the original key.
+* `OsString` gained a few methods, bringing it closer to parity with `String`.
+* Slices gained `copy_from_slice()`, a safe form of `memcpy`.
+
+**Encoding**
 
-* Raw pointers gained `as_ref()` and `as_mut()`, which returns an `Option<&T>`.
 * `char` gained the ability to decode into UTF-16.
-* `BTreeSet` and `HashSet` gained the `take()`, `replace()`, and `get()` methods.
-* `OsString` gained some methods to bring it up to parity with `String`.
-* `SocketAddr` and its variants gained `set_ip()` and `set_port()`.
-* Slices gained `copy_from_slice()`, a way to efficiently copy a slice.
+
+**Pointers**
+
+* Raw pointers gained `as_ref()` and `as_mut()`, which returns an `Option<&T>`,
+  translating null pointers into `None`.
 * `ptr::{read,write}_volitile()` allow for volitile reading and writing from a
   raw pointer.
-* `TcpStream`, `TcpListener`, and `UdpSocket` gained a number of methods that
-  let you set various aspects of the connection.
 
 Finally, many of the types in `libcore` did not contain a `Debug`
-implementation. [This was fixed](https://github.com/rust-lang/rust/pull/32054).
+implementation. [This was fixed](https://github.com/rust-lang/rust/pull/32054)
+in the 1.9 release.
 
 See the [detailed release notes][notes] for more.
 
 #### Cargo features
 
 There were two major changes to Cargo:
 
-First, Cargo has historically not been able to be run concurrently. [This has
-been fixed](https://github.com/rust-lang/cargo/pull/2486).
+First, Cargo
+[can now be run concurrently](https://github.com/rust-lang/cargo/pull/2486).
 
-Second, a new flag, `RUSTFLAGS`, [was
-added](https://github.com/rust-lang/cargo/pull/2241). This allows you to
-specify arbitrary flags to be passed to `rustc` through an environment
+Second, a new flag, `RUSTFLAGS`,
+[was added](https://github.com/rust-lang/cargo/pull/2241). This flag allows you
+to specify arbitrary flags to be passed to `rustc` through an environment
 variable, which is useful for packagers, for example.
 
 See the [detailed release notes][notes] for more.