brson

Servo is the kind of project that launches a thousand research papers. Some of the early results are staggering and the project is still just getting going. It is a great example of doing serious research to practical ends.

Some examples:

- firstly, the entire foundation, Rust, is itself an ambitious research project that solves many long-standing problems in the domain.

- Servo has, or has plans for, parallelism (combinations of task-, data-parallelism, SIMD, GPU) at every level of the stack.

- The entirety of CSS layout (one of the most difficult and important parts of the stack) is already parallelized, and it's fast.

- It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture).

There's an open issue for this: https://github.com/mozilla/rust/issues/13289

Rust can be called from other languages even with std. The main thing you'll be missing is the ability to handle task failure (which will just cause a process abort), but also protection from stack overflow. For full integration it will require a small amount of runtime API that is yet to be determined.

Maybe not. Rust is starting to mature and the code generation is already quite good (though there are still many opportunities for improvement). Hopefully this exposure will inspire people to improve these benchmarks. With a little effort Rust should be very competitive on them.

It probably should be reserved.

I like this a lot, and think it's the best intro to Rust yet. The thing that concerns me a bit is that it presents the special cases in concurrency without impressing some of the most important points. Primarily, the channel example presents the send as copying, which in this case it is, but one of the main advantages of Rust's channels and owned types is that message passing of heap-allocated types do not need to copy. It probably doesn't stress hard enough that Rust tasks do not share memory before saying, 'oh, but really you can share memory if you need to', though I see that the Arc and RWArc examples are good ways to introduce the concept of using unsafe code to provide safe abstractions.

I wouldn't want it to get too in-depth. Maybe just mention that this is a simple example but Rust prevents many other types of related errors.

Thanks for your report. I understand your frustration, and it's true that Windows support continues to lag. Some of the mingw dependencies were eliminated this release but not all. In particular, Rust still depends on mingw's linker. This is a major concern and Rust 1.0 will not be released without a self-contained toolchain on Windows.

Awesome post. All this discussion makes me realize that we haven't hit the sweet spot yet and need to keep considering more message passing use cases. I am wary though of providing too many options and very much want to have one channel type that is most useful and least error prone that we can recommend by default.

I do disagree slightly with the final conclusion that context switch on send defeats the advantage of unbounded channels since work stealing will ensure the sender runs again very soon.

The implementation on master currently uses a single queue, but very shortly it will be converted to work stealing.

Tasks can be 'pinned' to their own scheduler (i.e. thread) with `spawn_sched(SingleThreaded)`, and this is very important for tasks that call foreign code that blocks.

That's about the extent of the configurability at the moment, but I anticipate at least one other 'mode' in the future for coping with blocking tasks that don't want to be pinned to a specific thread.

It's not your misunderstanding, there is just very little library suport for managed vectors (and strings). For quite a while managed vectors did not exist, so owned vectors are everywhere.

The semantics of managed vectors and owned vectors are quite different and unifying the library code so that managed vectors are more accessible will be a challenge. It is a widely-felt problem though and some folks have ideas for solutions.

For now, it is best to use owned vectors, but there are two modules, `core::at_vec` and `core::at_str` that can help you if you need them.

I'm very curious about better ways to explain not just Rust pointers, but also other features that contribute to Rust's unique feel, like inherited mutability and linear types. These things are all interrelated and there are some emerging best practices, but they are still unfolding as the language evolves and people gain experience with it.

I'd recommend reading Tom Lee's post (linked previously) on the subject of pointers.

On the subject of libraries, there is a lot of work yet. The plan has been to get the language stabilized then start focusing on libraries and tooling.

The core and standard libraries are not very consistent, either in style or quality. The I/O modules (both file and network) are particularly problematic at the moment, so even a simple networking application will be difficult. Some folks have had success though by writing their own bindings to BSD sockets, ZeroMQ, mongrel, etc. (bindings for which are in cargo).

Outside of core and standard there have been a lot of graphics- and math-oriented libraries. Multimedia, particularly games, seems to be a very promising domain for Rust. There are a number of useful libraries that are not in cargo because cargo is not yet powerful enough to deal with their build requirements.

Some of the easiest, and potentially most useful, code to write when getting started are re-implementations of popular libraries, protocols, etc. in Rust. For example, I really wanted to implement mustache templates in Rust but somebody beat me to it.

Where 2012 was the year of stabilizing the language, 2013 will be for cleaning up and redesigning the libraries, and hopefully making all the tooling more usable and featureful.

This is not quite possible yet, but will be at some point.

Rust does currently depend on a language runtime which expects to control the execution of all Rust code (in particular managing the task scheduler), and the runtime does not have an embedding story yet. Even with an embeddable runtime though, the process would be more involved than loading a library through `dlopen` and executing a function.

As part of the effort to rewrite the remaining bits of C++ runtime code in Rust (almost all of Rust is written in Rust), there are further plans to make Rust code runnable without an underlying runtime and without split stacks. After that it will be feasible to write code in Rust and just call it like any C function.

There is no finalized spec (and the spec has actually fallen quite far behind for the moment), nor do I expect anything about Rust to be called 'final' for a while yet.

The upcoming 0.4 release (any day now) makes a big push to get a lot of the syntax pieces in place, but still has many rough edges. Beyond that the standard library is still an incomplete and inconsistent stew of different styles.

Rust is still firmly alpha software, but should stabilize significantly in the next year.

And the release announcement:

https://mail.mozilla.org/pipermail/rust-dev/2012-July/002087...

Annotations don't live within comments. The syntax for annotations is #[annotation]. They are part of the grammar.

Tests are mostly built-in to make sure there's no excuse to not test, but it is intended to be minimal and that other test frameworks can build off it (though it's not clear exactly how yet).