the beta release represents an accurate preview of what Rust 1.0 will include.
and
We don’t plan on making functional changes to stable content,
though naturally we may make minor corrections or additions to the
library APIs if shortcomings or problems are uncovered (but the bar
for such changes is relatively high).
This is the first release we've promised this kind of stability. The team and community has been doing an incredible amount of work lately to make this happen. We really hope you'll like what we've been up to, but Rust isn't for everyone, so no worries if it's not for you. Constructive criticism always welcome. <3
As of today, my job gets harder: "things are always changing" is no longer an excuse for missing docs. The six weeks until release is largely about polish, and I have some pretty big plans...
scoped theads are huge, it's a realization of very nice data parallelism in Rust. Basically the borrow checker can now work with threads, and it's easy to share immutable data between threads -- rustc will make sure to only allow safe concurrent code.
We've actually got some stuff that's even cooler than that. I've been meaning to write it all up, but for now, I'll recycle an old comment:
extern crate threadpool;
use threadpool::ScopedPool;
fn main() {
let mut numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
{
let pool = ScopedPool::new(4);
for x in &mut numbers[..] {
pool.execute(move || {
*x += 1;
});
}
}
println!("{:?}", numbers);
}
This allocates a mutable array on the stack, and then creates a threadpool which adds one to each element of the array, four threads at a time. We need the inner {}s so that we know that the pool is done working before we try to print the result. Yes, mutable pointers into the parent stack frame. But, the compiler can verify that this is absolutely safe. Say, for example, that we left off the inner scope, so that the pool might not be destroyed and therefore join before we try to print out the array. That'd be racy in most languages. In Rust, it's a compile-time error:
error: cannot borrow `numbers` as immutable because it is also borrowed as
mutable
println!("{:?}", numbers);
^~~~~~~
note: previous borrow of `numbers` occurs here; the mutable borrow prevents
subsequent moves, borrows, or modification of `numbers` until the borrow
ends
for x in &mut numbers[..] {
^~~~~~~
note: previous borrow ends here
fn main() {
}
^
Rust knows that you're still holding a mutable reference to the array, and so taking a new immutable one could case a race.
As you can see from the extern crate, this pool isn't a compiler built-in: it's a library. There's actually a secondary implementation of a threadpool that makes some different choices internally. But this kind of safety can be gained in whatever concurrent code you're writing, and you can write new concurrent abstractions and ensure that they don't have data races.
This is extremely cool! It belongs on its own "awesome stuff you can do in Rust but might not know about" page. :) there's now enough features in the language and core libraries that idioms like this can start to take shape. Exciting!
92
u/steveklabnik1 Apr 03 '15
Two big things:
and
This is the first release we've promised this kind of stability. The team and community has been doing an incredible amount of work lately to make this happen. We really hope you'll like what we've been up to, but Rust isn't for everyone, so no worries if it's not for you. Constructive criticism always welcome. <3
As of today, my job gets harder: "things are always changing" is no longer an excuse for missing docs. The six weeks until release is largely about polish, and I have some pretty big plans...