One thing I would emphasize is that Rust's approach to memory management (that is, avoiding a GC) can really dramatically effect the overall memory requirements of your application as compared with a garbage-collected environment. This is true of Go but also other garbage-collected languages. Reducing your memory footprint can in turn enable greater scaling and more even latency (no GC pauses). This isn't to cast aspersions on Go itself: their runtime is an excellent piece of engineering, and I know they've put a lot of work into minimizing pauses and so forth. But there are definitely benefits to Rust's ownership approach that show up in practice.

I wrote about compilation times here ; short answer: I see lots of reasons to be optimistic!

We're doing a number of things to bring down compile times. Obviously the biggest effort is the development of incremental compilation: it's been a long road, but we're really starting to see results, and I expect those to just keep getting better. See for example this thread on helping us to benchmark incremental compilation -- you can see that for a number of folks, the current system is already starting to work quite well, and there is still lots of room for improvement (for example, we never skip type-checking now). Besides incremental, I see a number of other promising things going on: The development of ThinLTO allows us to use a lot more parallelization without hurting the performance of the generated code. We've been moving towards a lazy compilation model, which should allow us to more quickly iterate and get to the stage of showing you compilation errors. That same move should eventually enable us to parallelize the compiler's internal workings (right now it is mostly single threaded). Our performance monitoring infrastructure has been completely reworked and is still being improved further. This enables us to see and catch performance regressions much faster. We've still not begun to optimize at the MIR level, but even doing some simple things such as inlining of smaller functions should allow us to reduce the amount of code we supply to LLVM. Better yet, those optimizations occur before monomorphization, so they pay off many times, since a single MIR function may wind up being generated more than once in the LLVM IR. Going forward, I'd like to see a stronger focus on "small bore" performance gains as well. Currently, from time to time, somebody finds an opportunity for gains -- but nobody is actively seeking them out on a longer term basis. I think it'd be great if we had a few people looking at profiles and trying to find those opportunities. Finally, as a kind of side note, we've been doing a lot of fundamental work on the workings of the trait system, which I expect to allow us to improve our trait resolution performance greatly. Since trait resolution currently accounts for a non-trivial fraction of our compilation times, this could be very nice.

You're reading my mind. =) I've actually been planning to start writing a little bit of such a book every day. The impl Period has really made it clear to me how much documentation we have yet to write -- I would like to see a book describing how every feature in Rust is implemented, that is kept up to date as new things come on. (OK, I know that's a bit of a daydream, but I still think we can do a lot better than we are doing, and I'd like to help move us there.)

We experimented a lot in this regard, and I think we will likely continue doing so. One thing that we found along the way is that it is very valuable to be able to look at the syntax and have a general idea of when a value is going to be borrowed or moved -- this makes a great deal of different with respect to what you can do with it! We also wanted to avoid the "implicit by-ref" that some other languages offer, where writing foo(x) can wind up mutating x , which can be quite surprising. That said, I think we've been evolving this story this year. For example, the default binding modes RFC allows one to drop a whole bunch of * , & , and ref when working with matches. I also experiment that some of the ongoing experiments around Copy type coercions will lead to similar improvements, specifically around types like &i32 , where the fact that a value is borrowed or not is not typically especially interesting. (As an aside, one pattern that I personally find nice is to move the & or &mut to the point where a variable is initialized. In other words, instead of doing this: let x = Foo::new(); use (& x ); You can do this: let x = &Foo::new(); use ( x ); This also serves as a way to signal to your reader that x will not be moved later on.)

Well, if you've got a taste for bugs, for one thing. ;) More seriously, it's a hard question to answer. I've found that I enjoy using Rust in a lot of domains where I wouldn't have expected to -- e.g., simple command-line scripts work out really nicely in Rust, and they run fast, too. But, overall, Rust is definitely focused on producing polished end-products -- if you want to make something temporary that you plan to throw away, Rust is probably not the language for you, at least not right now. (That said, I'd love to see us make more strides towards better support for "rapid prototyping".) I would also like to turn the question around: if you were trying a project in Rust, and felt that Rust was really not a good fit, I'd like to hear about it, and why. I'm always looking to know what we can improve. =)

I find this question very hard to answer. I don't know that there is any one particular thing that we need -- just a steady accrual of resources, as well as the simple matter of gaining more experience in teaching Rust to more diverse groups. It definitely took us some time and iteration to come up with our current methods of teaching Rust, and we are constantly trying to tweak and improve them. I personally believe that Rust -- or a language much like Rust -- could be a really great first programming language for people. I'd like people to learn the idea of ownership and resource management from day one, before they get used to the idea of omnipresent pointers and aliasing. (Many people who have not yet tried Rust seem surprised when I say this; I think they imagine that, when you don't have a GC, a great portion of your time is spent worrying about how to manage resources. I at least don't really find that to be the case in Rust: mostly I just write code, and the rules kind of guide me towards what is going to work.) Anyway, I definitely think that we should be working hard at figuring out the best ways to teach Rust to all audiences. Besides growing Rust, it also has the effect of getting us to think hard about the "essence" of Rust, which can help us to improve the language itself.

What is the plan regarding Rust and Gnome? Is there a complete integration of Rust and GTK planned? I don't know that there is an official plan -- and certainly not an official commitment -- but yes there is ongoing work on making it possible to use Rust seamlessly within a GTK-based system: that is, to access objects written in C (or other languages) and to export objects from Rust for use by other languages. Federico Mena Quintero , for example, has been doing great work on extending the gnome-class plugin, which lets you write GObject-style classes on Rust, and on integrating that with the excellent gtk-rs project, which lets you access all the GTK libraries and so forth from within Rust. See for example this recent thread bikeshedding how to integrate signals and other features . I really enjoyed the GNOME-Rust sprint that we did in Mexico City -- it was a lot of fun to meet the GNOME developers, and I walked away with a real respect for the excellent engineering that has gone into that codebase (I also thought in general that the two projects were a great "cultural fit"). There is also a second sprint in the works -- I'm sad because I won't be able to attend this one in person, but I'm excited to see what comes out of it.

I definitely think Rust can be very helpful here. The same rules around aliasing and mutation that come from ownership + borrowing can also help a formal verification tool track the current state of a value in a more detailed way. But I don't know of any tools that are usable at this very moment for doing this sort of thing with Rust code (*). It's always been a dream of mine, however, to deploy tools like that on the standard library and other widely used bits of unsafe code. (*) EDIT: As others noted, there are some in development.

I'm not sure just where we issue warnings, but it's certainly true that doing a glob import across crates can carry a measure of risk, since as new versions of the crate get published, that glob import can bring in more and more things. This is mostly problematic if you have two glob imports, because they might wind up conflicting with one another (if you have only one glob import, those names automatically take lesser priority to other, explicit imports). In any case, I could imagine adding some kind of warning for glob imports across crates. Clippy likely has one already. Still, I think we want to be somewhat careful with the things we warn about -- Rust already issues a lot of lints by default. I've found these are super helpful for finding bugs, but can be kind of annoying when I'm just trying to hack something up and get it to work (precisely the sort of time I might be inclined to use a glob import). I've always wanted to see if we can find some kind of way to help strike that balance a bit better. (Part of the problem, I suppose, is that the compiler builds with #[deny(warnings)] , which makes it awfully persnickety.)