Rust Language Team

A systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

Hosted by

Steve Klabnik's photoAaron Turon's photoErick Tryzelaar's photoNiko Matsakis's photo

2nd November 2017, 6:00 pm

This AMA is over!

Thank the host

Message from the host 馃挰

Hey y'all! A subset of the Rust core team is now here and we'll be answering from our personal perspectives. Keep the questions coming!

EDIT: And we're done! Thanks for the great questions, everyone! This was a lot of fun.

Does pineapple belong in pizza?

If you like it, sure. The great thing about pizza is that you can put so many things on it to suit your tastes.

Dear lord, no. Also I use emacs.

Why you gotta be like that Aaron? Vim all the way. It's how I got involved in Rust back in 2011.

Hi Rust team! Thanks for doing this AMA. One question that beginner developers always ask about Rust is:

With C++17 being such a great and easy-to-use language, why would anyone use Rust?

Would love to hear your thoughts on this.

I definitely agree that C++17 is a great language; but I think Rust brings a lot to the table. The most obvious thing of course is safety. Despite all the advances that C++17 has made, it is still quite easy to produce a data race or to experience iterator invalidation. These sorts of bugs become a real drag on productivity -- and fear of these sorts of bugs can prevent you from doing the kinds of ambitious designs you would really like to do.

In the talk I gave at C++Now, I told a story about how -- while editing the compiler -- I accidentally introduced a data race. Or at least, I would have, had the compiler not caught me. I think this story kind of gives you a feeling for what I'm talking about: what could have been a major bug that took forever to track down was instead just a minor roadbump, quickly identified and circumvented.

That said, there are a lot of reasons to use Rust beyond safety. Having access to Cargo is a big one: I love having great libraries available just by copying a line or two into my configuration. (I love not having to remember how to write a Makefile, for that matter.) Being able to use use enums to structure the various cases I have to consider really helps me keep track of what's going on. The macro system is way more powerful and can help automate tasks that might otherwise be a chore. Finally, traits often allow you to setup really elegant structures where a number of simple rules combine to make for very concise, readable code.

This is a fantastic question.

First off, I should say that C++ provides some excellent competition; it's very impressive how the language has evolved.

That said, there are some strong reasons to consider Rust instead, both in terms of fundamental and more surface-level differences.

On the fundamental side of things, Rust provides some iron-clad guarantees about your code that are really vital for systems-level programming. Rust code cannot accidentally read from freed memory or clobber data owned by someone else. It's also guaranteed to be thread-safe. While recent improvements in C++ make it less likely that you'll make some of these mistakes, it's still very much possible to do so.

Why do the guarantees matter? They let you set your ambitions higher. If you're a C++ dev, you've likely learned to be very conservative -- copying data because you're uncertain about the ownership, or using atomics because you're unsure what concurrency might be at play. When you write Rust, you can be bold: you can avoid these high-overhead safety measures, and the compiler will tell you if something could possibly go wrong. In practice, this means you can write higher performance code in Rust much more quickly than you can in C++. And that's played out in production, with cases like the recent style-system rewrite (from C++ to Rust) that's shipping in Firefox in a couple of weeks.

What if you're not a C++ dev already? Say you're a JS or Ruby dev running into some perf problems. Rust's guarantees also make it much more attractive to you than C++, because you can dabble in using a small amount of Rust in a core component, without being afraid that your app is now going to crash due to a segfault, or worse -- be exploited by a hacker.

Someone else want to touch on the more surface-level differences?

Oh, one more point about the fundamental differences: with Rust, the types tell you so much about your code. Knowing for sure, by looking at a function signature, whether the function can mutate the data you've handed to it, or whether it expects to take or return full ownership, is a massive help in navigating or refactoring a large code base.

Here's a post with some more details on how Rust can raise your ambitions when it comes to concurrency:

Can I replace my Rails/Django/Flask with Rust? Is it ready for web development already?

Maybe. It's very early days for this in Rust; there's no community consensus around web frameworks. This means that there are a lot of options! It also means that there isn't a huge library ecosystem for specific tasks.

If you can afford to author a few libraries where stuff is missing, then it may work well for you. Or if your sites are simple. is written in server-side Rust, for example, as is, which is Rust on the server and Ember.js on the client.

This year, we've been working hard to shore up the basics around servers in Rust. By the time 2017 ends, we should a relatively solid and stable web framework at the level of Sinatra. Rails, on the other hand, is still some distance off, though there's definitely interest in pursuing it.

More broadly, there's a lot of demand in this space, and I personally believe this is a great area for Rust to continue growing in, because it puts helpful pressures on our story for ergonomics and productivity.

To add to Steve, there's also a great website, Are We Web Yet, that literally tries to answer this question. The biggest web frameworks that I know of (in alphabetical order):

There are a number of companies using Rust Web Services in production, but offhand I'm not sure which frameworks they are using.

I feel learning Rust needs functional programming experience, being coming from C background I am facing difficulty in solving problems rust way.

I would like to learn rust by contributing to the open source code, for now can you please recommend some rust projects where I can contribute as a beginner?

I am also interested in embedded systems, what's the plan to support micro-controllers like ARM cortexM3 and friends? Is anybody is doing work on this?

I would disagree a bit that functional programming experience is needed. While Rust definitely employs ideas that originate in functional programming, these ideas are increasingly common-place -- lots of languages have closures today, for example. That said, these FP-inspired features are often a thing that people love about Rust, if they haven't encountered them before.

In terms of places to contribute, I'd point you to to get started -- we've put a ton of effort into setting up groups and mentoring to help people get involved.

Finally, for embedded systems, we already support a fair range of targets, with more coming all the time. Right now the ecosystem is pretty hobbyist-focused, but we consider this an area of great potential for Rust. Check out for more!

As for contributing, there's a big drive right now to get people involved with Rust itself and related projects! See for a big list, or to just dive in.

There's a lot of work on ARM! Check out; you use the thumbv7m-none-eabi triple for the M3. is also a very interesting project I'm excited about.

What is your personal vision for Rust in 10 years? I'd love to hear a few random interesting personal highlights from what you hope or envision the Rust language or ecosystem looking like 10 years from now in 2028. Specialty, language feature, adoption pattern, notable success story, however you envision it!

Fun question! Given that Rust 1.0 happened less than three years ago, it's really hard to predict the next 10! But I can mention a few hopes and dreams.

  • A ton of Rust code should be shipping in Firefox. That's already well underway; you can read about that work here and here

  • We should have a number of big, foundational internet companies using Rust for core services. Dropbox was one of the first where this happened, but there are more in the pipeline (which I can't give details on here). Rust has a very clear value proposition in a lot of these cases: low, predictable memory footprint; steady, strong performance; the productivity and protection of higher-level languages like Go.

  • I want Rust to be the systems language for the web. WebAssembly now means that the web offers a low-level VM, but right now it's mainly targeted by legacy C++ codebases (games in particular). Rust is poised to enter this space strongly: JS framework authors should be able to pick up Rust much more quickly than C++ (see earlier questions for why), and use it to boost perf-critical components. Since Rust doesn't need garbage collection, it's a lot easier to ship to the web than most other languages. To put it most strongly: what C is to Unix, Rust should be to the web/wasm world.

  • In terms of the language itself, I'd like to see a continued focus on programmer productivity, but also grow stronger in hard-core systems spaces (embedded systems, crypto, etc). We've got a lot in the pipeline here already!

In ten years, I'd like to see Rust become the default systems language of the web. I talked about that in another question though, so you should check that out :)

In ten years, I'd like to see Rust be taught in universities as the go-to low-level language.

In ten years, when someone asks "We need more performance, how do we get it?", "Rust" should be the default answer.

In ten years, I'd like to see be one of the largest package ecosystems in existence.

In ten years, I'd like to see dozens of books on Rust.

In ten years, I'd like to see Rust have a formal, proven memory model, with fantastic tooling for unsafe code.

Complex constraints and code abstractions can be handled in different ways, including with advanced type systems including higher-kinded types (as in Haskell and Scala) or by including advanced code-generation capabilities (as in C++ templates and Scheme macros). Both come with drawbacks, however (large learning curve and difficulty in figuring out where behavior is coming from, respectively).

Other languages (e.g. Go) eschew such features. This makes programming feel simple; simple tasks are simple to understand, and you handle complexity face-to-face (manually--the compiler doesn't help you).

Rust already has a sophisticated type system (especially if lifespans are counted), a robust macro system, and plans are underway to add to both capacities. What is the ideal end-goal? Is there a balance to be had between language simplicity and language expressivity? When should the type system carry the burden of taming complexity and when should metaprogramming (macros)?

These questions really strike right at the heart of language design philosophy! Here's my perspective.

In Rust, we try not to be too dogmatic about attributes like "simplicity", "expressivity", and so on. Instead, we're driven as much as possible by use-cases and programmer experience. So, taking higher-kinded types as an example: we've so far avoided adding them, waiting for strong demand and clear use-cases to emerge. While we now have a design that touches on HKT, we're also taking the most simple-minded approach we can that solves real-world use-cases.

This year, we've been really focused on reducing the learning curve, and increasing productivity around Rust. To do that, we've found ways to simplify or clarify existing features that benefit new and existing users alike. In some cases, this means using the information the compiler already has to avoid the need for you to jump through extra hoops. We've done this work with utmost care, ensuring that these improvements don't involve hidden complexities that you have to grapple with eventually. You can read more about the effort here.

The question of expressivity via macros vs the core language is an interesting one. To some degree, we see macros as a way of prototyping things that might become core features eventually; we're developing our async/await story this way.

While Rust libraries definitely do employ macros to do some pretty spectacular things, there are also some particularly common ways to use macros that don't feel so mysterious -- like automatically implementing traits for a particular struct. In my experience, as a client of these macros, I virtually never need to know anything about their implementation.

What RFC or other language feature are you most excited about in Rust?

I am personally very excited for the combination of in-band lifetimes, impl Trait, default binding modes in matches, and non-lexical lifetimes -- these together promise to remove a great deal of 鈥渆veryday friction鈥 from the code I write. The nice thing about these features is that I think they will make the overall language feel simpler overall, which is a rare thing.

(In terms of "fancier" features, there's lots of nice stuff coming down the pike too -- generic associated types and const generics come to mind as things that I can see myself using regularly.)

I'm excited about all our ergonomic improvements this year, but if I had to pick:

  • impl Trait -- it was my first RFC! It's been a long road, and is going to be a huge deal.
  • Generators, and more generally the path toward a really solid async/await experience.
  • Stable SIMD support.

I鈥檓 really excited for coroutines, not just for async-await, but for a simple way to define complex state machines. I鈥檝e done some preliminary experiments and I鈥檓 pretty sure we could speed up serde deserialization maybe 10-20% by using coroutines for even more optimal buffering.

Non-lexical lifetimes would be nice too. It's not that hard to work around lexical lifetimes, but it'd be nice to avoid that papercut. It is however one of the big complaints I hear from new Rust developers.

Oh, and Macros 2.0. I love doing stupid things with compiler plugins (like stateful, a failed attempt to make a compiler plugin for coroutines). It's going to be so much fun when we have the ability to transform Stable Rust AST.

After custom derive landed in 1.15, I lost my good answer to this question ;)

I'd say the default binding modes in matches, non-lexical lifetimes, and impl trait. The first one is something I run into all the time, the latter are things others run into all the time.

Are there any plans for any sort of official (or at least standard) GUI solution in rust?

Not at present. There are bindings like that are usable today, but standardization is some distance off.

No plans now. One of our driving philosophies is that we truly want the language and the standard library to be stable in order to make it easy for users to upgrade when we release every 6 weeks (known as the train model). The consequence of this is that we are promising to support that anything added to the standard library. If we followed Python's "batteries included" philosophy, those libraries would be quick to atrophy as we learn better ways to implement things.

So instead we developed Cargo to make it as easy as possible to depend on external resources. There are a few projects trying to make GUIs easy to use with Rust, which you can see on Awesome Rust. I believe the most advanced integration is with GTK, but I don't have much experience in this space, so I could be wrong.

Explain like I'm 5: Why would I want to use Rust rather than C? Give as many reasons as you can.

Well, not having to start your project by writing a hashtable is certainly a plus. ;)

In general, I'd say that everything we said about C++17 also applies here, but even more so -- e.g., C lacks generics, which means that you either have to write code that uses void* as a stand-in for "some type" (forcing you to use pointers), or else write complex macros or python scripts that generate different copies of your types (been there), or... well, that's kind of it.

Do you think every security related C code should be rewritten in Rust to prevent vulnerabilities like Heartbleed in the future? And are there already any plans of famous projects to do this?

Engineering is all about trade offs. Saying everything should be re-written in Rust is bad engineering. There are valid reasons to keep writing C code. Your project may have one of those. It always depends.

That said, for new projects today, in general, I'd prefer to see them started with Rust than started with C, if all else is equal. It always depends.

Possibly the largest and most well-known C++ project being re-written in Rust is Firefox. Its next release in a few weeks, 57, contains a host of improvements, but one of the ones I'm most excited about is Stylo. It's Servo's CSS handling, but in Firefox. This means that hundreds of millions of people will be using code written in Rust, and I find it thrilling.

To riff off of what Steve said:

one of the ones I'm most excited about is Stylo. It's Servo's CSS handling, but in Firefox. This means that hundreds of millions of people will be using code written in Rust, and I find it thrilling.

This is indeed thrilling, but one of the most interesting things (to me) about Stylo is that it's a great example of how you can integrate Rust into an existing project without rewriting the whole darn thing. Although the Stylo engine is written in Rust, at least in Firefox it's configured to operate over the Gecko DOM, which is all written in C++. If shipping Stylo had required rewriting the DOM, it would never have happened.

(Also, if you've not seen it, Lin Clark's excellent blog post about Stylo is also worth a read.)

Another great security project that's starting to integrate Rust is Tor. They talk about the branch here.

Do you have any wishes or plans 鈥 no need to be concrete ones or anything 鈥 to address the "rental" problem? (References to other fields in the same struct?) I feel that that is one of the next big expressivity problems in the borrow system after non-lexical lifetimes.

I agree that this is one of the next big expressivity problems. I don't yet feel like the answer is particularly clear -- personally, I'd like to start by digging more into the use-cases, and trying to understand more deeply what the constraints are (as a simple example, how often is it that you want a pointer to another field of your struct, versus a pointer to data in the heap that is owned by your struct?). The precise constraints can make a big difference here to what can be done safely.

In any case, the most obvious bit of pending work that is related is the ?Move RFC -- which enables types that cannot be moved once they've been borrowed -- but it doesn't directly solve "the rental problem" writ large.

TL;DR, I see a lot of iteration in our future here =)

To add a bit to what Niko said: I anticipate this being a pretty major focus next year, as we try to make our async/await story as strong as possible. That said, I think we should approach it incrementally, and get these key use-cases covered ASAP before going fully general.

What do you think the Rust language and ecosystem needs before anyone, even complete beginners to programming, can come in and start writing Rust?

People learn C++ as their first language so Rust is definitely possible too. :)

I agree it's possible!

I think we need a book + practice problems that focus on this audience.

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.

Besides "The book", do you guys recommend any other book? I've been struggling for a while in my path of being a Rustacean.

I really love Gankro's writing:

I'm excited about the O'Reilly and Manning books, but have not yet read them.

Rust by Example is a great resource as well.

I have come across a Blockchain project where in Rust is being used at the core. Can you tell me how does rust compare to Go for network concurrency stuff? or whats the difference between them and where would I use which one?

Go bakes in a particular model for network concurrency: you write blocking code, and the runtime does async io for you, switching between goroutines as needed.

Rust, on the other hand, does not bake in any particular IO or concurrency model. This means that you have many options; it also means that it's taken us a lot longer to come up with good defaults :) Tokio presents a single-threaded model for non-blocking IO based around futures. But you can also use a lower-level library like mio, writing your own event loop, or you could choose to directly bind to your operating system's IO model. It's up to you.

It's the same with concurrency: Rust gives you access to the tools you need to use your platform's threads, or to write your own green threaded runtime on top of them, or use someone else's.

Oh, I forgot: so these differences in approach correspond to how you make that choice: Go is convenient, but comes with drawbacks, such as a non-zero cost to call into C code. Rust gives you much more flexibility and power, but also, that means less ecosystem uniformity. Which one is best for your situation is a question only you can answer for yourself :)

Hola Rust gang! What advice you have for beginners coming from python and javascript backgrounds with out any low level programming experience. Any resources targeting them ?

The book is written without the need to have low-level experience; many Python and JS people have told me that they learned well from it.

As far as advice, the biggest hurdles you're going to have are: generics, pointers, and thinking about scopes. It's not insurmountable though! I myself primarily did Ruby before Rust, though I did learn C long long ago.

What got you involved with Rust?

What's the plan with RustBridge? It's interesting, but the website doesn't seem very active.

I came from an academic research background, and a lot of the work I did there had all kinds of connections to Rust's core ideas (ownership, safe systems programming, etc.) I was very lucky to be on the job market when a position opened up on the Mozilla team, and I've been there ever since.

More interesting, perhaps, is what keeps me here. There's a wonderful spirit around Rust and its community -- the sense that Rust is an enabling technology that can empower people to do things they thought were out of reach. We're always looking for new perspectives on tradeoffs, to "bend the curve" and try to have our cake and eat it too. The excitement and vitality of the community, and the way we make decisions together, makes me happy to come to work every day.

re: RustBridge, it's actually quite active! In the last ~month, I think there have been at least three events, and a teacher training is planned for January. You might keep an eye on

I answered the former elsewhere, so I'll stick to the second: are you sure you're looking at the right site? is the correct one. We just held a RustBridge a week ago at Rust Belt Rust, and another one at RustFest Zurich at the start of the month!

One upcoming plan is a teacher training, early next year, to help teach people how to run their own Rustbridges.

In what cases you wouldn't recommend using Rust?

One clear-cut case are proprietary embedded systems; they usually give you a private fork of GCC. Trying to shoe-horn Rust in there isn't going to be a good time.

A second is if you don't care about speed or correctness at all. That may sound silly, but you'd be surprised at the number of projects that don't need serious engineering, they just need to knock something out and it's good enough, or something that's only ever going to run a handful of times.

Rust isn't very strong for prototyping; it's much more geared toward long-term robustness. So if you're just trying to throw something together quickly, I wouldn't reach for Rust at first. But of course, those quick little projects have a way of sticking around...

More generally, I think Rust's strengths are around performance (both throughput and latency), memory footprint, predictability, and writing robust, maintainable code bases. If you don't have needs in one or more of those areas, there's probably a language that's better suited for your task.

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. =)

For someone who wants to start contributing to the Rust community, what libraries seem to be missing that you think would be most beneficial? And anything simple enough that someone without much experience in Rust could start working on?

Wonderful question! We have a community effort going on now called the Libz Blitz, which is trying to make it easy for people to start contributing to significant projects and get them to reach a 1.0 stability.

WebAssembly is on track to receive a number of features to improve targeting it from languages with large runtimes. What wasm features would you like to see to help Rust be a useful choice for libraries and applications on the web? What work might be done on Rust and in the ecosystem to make it more competitive when targeting the web?

I personally am most excited about Rust's future with WebAssembly. Wasm is the assembly language of the web. JavaScript is the application language of the web. Rust should be the systems lang of the web. Systems languages succeed because they鈥檙e the native language of the platform. For the web platform, that language should be Rust. If you need to do a systems-level task on the web, Rust should be the default choice the same way C is the default choice for systems today.

We have a ways to go to accomplish that goal, and it's going to take a lot of work, but it's one of the areas I'm most excited about for the future.

Your question is about how we get there. On the Rust side, the biggest thing is making it easy to compile to wasm. We're not that difficult, but getting emscripten set up is kind of a pain. I want to make targeting wasm as easy as targeting musl libc; that is

$ rustup target add wasm
$ cargo run --target=wasm

Or whatever the triple ends up being.

The second biggest thing is on the wasm side: right now, wasm can't access the DOM directly, but must "FFI" through JavaScript. It has a pretty huge performance penalty. It's also a similar story with threads.

Community-wise, testing against wasm in CI would be great. Given the aforementioned setup difficulties, I don't think we're ready for that as an ask yet, though.

To add a bit to Steve's answer: on the wasm side, there's work just getting started in exposing the DOM in a way that Rust can easily work with, without requiring full GC integration (which is still years off). That will immediately increase the power of Rust on the web, and we hope to have the Rust side of that story ready in lock-step with it becoming available.

That said, Rust is already usable via wasm for cases that are not DOM-heavy, i.e. if you have pretty compute-heavy components.

Finally, within the Rust ecosystem, I expect we'll have an explosion of libraries for working in wasm (and binding to web platform APIs, as well as ultimately js libs). The cool thing is that this in many ways resembles the no_std/embedded story for Rust, because wasm out of the box doesn't even give you malloc, let alone files etc. Moreover, wasm often has much stronger binary size constraints than even embedded devices. So I think that working on the wasm-centric ecosystem will also help us push Rust for embedded.

I wanted to learn Rust for project, but I think the syntax of the language is quite complicated. In what other development environments can I use it and why it is better than Python or for example Java?

Thanks in advance.

P.S Language actually is very interesting, I think that it has a really lot great features built-in.

Go Rust ! 鈿欙笍

In what other development environments can I use it

Rust is a general-purpose language, so, lots! We support Mac/Windows/Linux, as well as a range of embedded devices and other operating systems. You can also write your own OS in Rust too :)

and why it is better than Python or for example Java?

You'd need more context to say why here; for example, Python is probably easier to learn than Rust, so saying Rust is always "better" is a bit of a misnomer.

One big thing that differentiates Rust from these languages is that Rust doesn't have a VM or runtime the way these languages do. This also means no garbage collector. This means that Rust can reach much farther down the stack; operating systems, device drivers, etc. It's not impossible, technically, to use those languages in these environments, but it's a snap with Rust. Rust will also use much less memory, and have more predictable performance.

Would you recommend Rust as your first programming language?

Sadly, I can't recommend it today. I used to teach programming professionally; beginners need totally different resources than people who have programmed before. We don't have those resources in Rust. Maybe someday!

What is the plan regarding Rust and Gnome? Is there a complete integration of Rust and GTK planned? In a few years, would it be possible to use Rust for high quality GUI's on Linux? Could such GUI's be ported to the web through Webassembly?

I've been longing for a clean, integrated, powerful, native GUI toolkit for a long time, and I was hoping maybe Rust could be just that ...

In other words, do you eventually envision Rust able to write both the application logic as well as sophisticated graphical stuff?

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.

How stable is Gotham? Would you recommend using it to build high scale production ready apps?

I haven't personally used Gotham, so I can't say either way. I'm excited to see projects like it popping up though!

I haven't tried it either, but if you want to compare Gotham with the other web frameworks, check out rust-web-framework-comparison, which re-implements a simple Hello World service in the various frameworks.

Pi or Tau for the ultimate circle constant?

I know Tau is "more right" but... Pi.

I've seen a lot of comparisons recently between Rust and Swift. How do the two compare, and do you view Swift more as competition or as a complement?

Rust and Swift are kindred spirits; fellow travelers who walk similar paths.

Both have constraints that inform their designs and decisions. Swift has strong constraints around Objective-C compatibility and being an Apple-first technology; Rust has a desire to give you access to every last bit of performance, and motivation to have good support for a wide variety of platforms.

I view the two languages as complimentary more than competition.

I see them as pretty complementary, at least right now.

Swift and Rust definitely have a lot of ideas in common, and Swift is even exploring some of the ownership tech from Rust. Where they most diverge, though, is their goals.

Swift's aim, as I understand it, is to be an awesome application-development language, first and foremost. Rust is more aimed as systems development, first and foremost. Each one wants to branch into the other space, but the deep difference in starting points already makes them quite different beasts.

In particular, there are some core aspects of Rust that I can't see us ever changing, nor can I see Swift ever adopting:

  • Rust intends to be usable in as many environments as possible. Thus, it has no runtime, no GC, speaks C natively, and generally speaking can be "just tossed in" as a lightweight component.

  • Similarly, Rust is unwilling to forcibly impose costs or abstractions on top of the underlying system. If you want to work at a higher level, you can do so, and we give you lots of great tools to do so. But we take as a constraint that it's always possible to drop down to "bare metal".

  • Put differently, Rust intends to be appropriate for writing an OS or database in.

  • Rust as much as possible avoids "legacy commitments"; at the libcore level, there are no assumptions about even the surrounding operating system.

That said, we often talk about Rust having three core goals which I think Swift shares: it should be fast, reliable, and productive. I think a lot of the differences between the two come down to a different choice of how to balance between those three goals.

What do you think about Rust applicability in the field of cryptography? Not only in technical terms, but also regarding how to attract professional cryptographers to write in Rust. Can we in 5-10 years get a pure Rust OpenSSL replacement which hopefully will be free of all those horrible memory bugs or there is some obstacles which will be hard to overcome?

There's lots of great working going on here!

Specifically with regards to "pure Rust OpenSSL", is an in-progress, bit-by-bit port of BoringSSL to pure Rust + asm.

I'm currently working on code involving cryptocurrencies like blockchain explorers and market aggregators. I know many languages but I mainly use Go and Rust for most things. Unfortunately, this project is going to be very large and I was not comfortable with the delays Rust imposes on the code-build-run cycle, so I went with Go for the core of this project (though I use Rust for other smaller services).

I know incremental compilation has landed and helped a ton, but it's still magnitudes slower than Go compilation. Is there any plans to improve this and is there a timeline (like alternative compiler backends)?

Incremental compilation hasn't been fully delivered yet; in the next several weeks, we expect to be able to start skipping earlier compiler phases like type checking, which should make a huge impact.

The Rust team is very aware that compile times are a big problem, and while we expect by the end of the year for incremental compilation to help a lot, we don't plan to stop there. Next year we will continue pushing through incremental compilation further into the compiler, and also explore algorithmic improvements around the trait system which should speed up all builds.

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


Are there any plans for other platforms to use rust as a primary language? E.g. how the Android framework is with Java

I'm not aware of any, but as I said in another question, I'd like to see heavy use of Rust with WebAssembly.

Google's Fuchsia is at least adopting Rust as a contender for a lot of the layers surrounding the kernel. Whether it becomes the primary language remains to be seen.

Hey! I'm one of the organizers of the Rust NYC meetup. If any of y'all (whether you're part of the Rust team or not!) are interested in presenting, we are always looking for speakers. Message me through meetup :)

I live in Brooklyn/Queens (Technically I'm half a block into Queens but it's not like, really Queens), so we should do it!

I'm sadly not in NYC, but I do run the San Francisco meetup (where we are hosting a meetup tonight with a live stream if you are not local).

If anyone is interested in attending (or speaking) at a meetup and you're not in NYC of San Francisco, we have 89 known meetups around the world. Feel free to contact them, or or open a ticket on our community talks repository and we'll help connect you with the local groups.

What are the risks that a programmer ought to be aware of when using features only available from rust nightly?

The main risk is that your feature may change at any time, it may be removed. Basically, you cannot rely on it at all.

It's also an opportunity to get involved with Rust's development though: making your case for why the feature works well today and should be stabilized is very useful to us, so we appreciate people who try things out in nightly.

It really depends a lot on the feature. In some cases, features are relatively stable from the day they land in nightly, and you may never have to update your code. Others are known to be more experimental. We've considered having a finer-grained feature opt-in to make this more clear, but you can always ask the Rust devs.

What you think about Linear Haskells idea of using linear functions instead of types? Would that have been good enough for Rust?

(Submitted on 26 Oct 2017)

I haven't read it yet, so I can't say.

If you could create a new English word, what would it be and what would it mean? Your favourite word (Not necessary English one)?

what about rust-lang learning resources? "Ask about Getting started with Rust"

Hello and thanks for the AMA! :)

How did you guys end up being part of something as cool as Rust, and what advise would you give to a dev at the beginning of his or her career in tech?

Hi! :D

I was visiting my family for Christmas back in 2012, and saw this on Hacker News:

I decided to check it out, really liked it, and went on to write up my experiences as "Rust for Rubyists", which lead to me contributing to Rust's official docs, and now here I am today :)

Why does not pass variables by reading by default? Rust is plagued of '&'.

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();

You can do this:

let x = &Foo::new();

This also serves as a way to signal to your reader that x will not be moved later on.)

Any plotting library for scientific community?

There's RustGnuplot, but I've never tried using it. I know the scientific community is really into Python these days, so another option to use pyo3, rust-cpython, or rust-numpy to use Python tools to explore Rust objects.

Compile times

What is being done to bring compile time down?

How much slowdown do you see in Firefox build times, now that parts of the browser are written in Rust?

Compile times have been a major focus this year, and by the end of 2017 we expect to deliver massive strides here.

We've been looking at:

  • Incremental recompilation. This is by far the most important work, which allows us to reuse most of the work done by previous compiles. You can see some of the current results here.
  • Parallelizing code generation, with ThinLTO to keep the resulting binary optimized.
  • Various spot improvements to data structures and algorithms.
  • Algorthmic improvements to the trait system (probably won't land until 2018).

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.

There are lots of great language improvement ideas flying around in the RFC repo. Non-lexical lifetimes, module system revamp, const fns, variadic generics, extensions to the trait system, and so many others... I assume there are a lot more people proposing ideas than people working on the language, so how do you manage to cope with the flux, examine all of the proposals, and prioritize those that get accepted for implementation?

Also, to expand a bit on this question, how do you interact with people who have a good intuition when it comes to language ideas, but would not translate these ideas into a formal RFC form due to fear of general lack of spec writing skills? There are plenty of people out there who are better at thinking or coding than technical writing.

One thing we're trying out this year is the "impl Period"; that is, there's a moratorium on new RFCs at the end of the year. This, combined with our yearly roadmap, helps us focus on shipping, rather than solely paying attention to new proposals.

We often try to prioritize RFCs based on user feedback; that is, if the lack of something is causing a lot of pain, we put it very high up. More theoretical stuff is only really considered in the context of "how does this solve real problems people have with Rust today".

Regarding intuition, people will often work with others to write up RFCs, and the whole point of the review process is to improve the spec before acceptance.

I love this question; it really hits on one of the biggest challenges in my day-to-day life.

So first off, OSS if done right is fundamentally chaotic. People are coming and going, have their own goals and angles, and somehow the project needs to turn all of that energy into a coherent direction. It's not easy! And you can't do it perfectly.

That said, what we've found this year in the Rust community is that the best thing we can do as a community is:

  • Set out various rhythms. We have things on a yearly cadence, a quarterly cadence, a six week cadence. Having these "seasons" to the work that happens helps you stay focused and not feel like you're dealing with an endless slog.

  • Be very clear about goals for a given part of the cadence. For example, each year we have a roadmap that's decided on with broad input and driven by a bunch of data (like the survey). Throughout the year, the various Rust teams keep coming back to this roadmap, prioritizing things relative to it and making sure we're making steady progress.

So the principle is that, on the one hand, you want to allow for that magical OSS serendipity, where someone amazing unexpectedly shows up and hands you something that might not have been on the roadmap, but is super valuable. But on the other hand, you want to have some sense for overall direction and priorities, so that you can make sure the most vital improvements are actually landing.

The Rust community is very much still on a learning curve here. I think this year has shown a lot of success around these processes, but also plenty of failures, and I'm hoping for 2018 to reboot a bunch of aspects of how we operate to try to hit this balance better.

how do you interact with people who have a good intuition when it comes to language ideas, but would not translate these ideas into a formal RFC form due to fear of general lack of spec writing skills?

Another incisive question!

In general, the Rust community strongly believes that there are many different kinds of valuable contribution, and strives to enable people to bring their unique skills to bear.

This is an area where I'm super proud of what we've done with Rust. There are folks who have written extremely important language design RFCs who don't know the first thing about the compiler. Some of them are now members of the formal language design team!

As to your question about formal spec-writing, we offer a lot of venues for people to pitch "pre-RFC" ideas -- whether on our discussion forum or IRC. Generally we try to pair up folks with complementary skills but a common goal, and deliver things that way. It can be hard to manage, but it works!

Thanks again! The way you phrase it, managing a large-scale public open source project sure sounds like a good balance of challenging and exciting!

Does the fields in traits RFC stand a chance at getting merged in Q1 2018?

Definitely! There aren't any serious blockers, it's just been on the back burner. If an enterprising community member wanted to help push it along...

Will there be a gitbook on how to approach hacking the rust compiler

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.)

Not literally a gitbook, but we are trying to improve documentation on working on the compiler.

What would be the hardest question you could be asked? :P

Is science invented or discovered?


As someone who previously had a research career, I think both views are critical. Discovery requires creativity. Inventions require contact with the real world.

In the programming languages realm, you might imagine it's all invention, but that's faaaaar from the case. For example, some of the core ideas in Rust about ownership descend fairly directly from a highly useful connection between mathematical logic and programming languages.

I'm a beginner learning about server deployment. I started like most newbies learning JavaScript, and now I'm moving to Node.js but wish to learn a compiled language like Go or Rust.

Are there any advantages of using Rust over Go?

Rust lets you "reach lower" down the stack than Go does, as well as using less memory. There are prominent Node people in both languages; for example, tj moved to Go long ago, and Node shops like npm are deploying Rust today.

Finally, it's easier to extend Node with Rust than Go, since Rust has no runtime. is a great example of this, and we're working with the Webpack team so that you'll be able to just drop Rust code into your project and have Webpack do its thing, producing webassembly that your Node can use.

Finally, it doesn't have to be an either-or: Dropbox is using both Rust and Go where appropriate.

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.

A large fraction of the Rust team works at Mozilla, and I've always been a bit curious about how that came to be. I mean, I work with some MLOCs of hairy legacy C++ code at work, so I can understand the desire to have a better systems programming language, but there is a difference between dreaming that and hiring quite a large team to actually make it happen! Could you give me a bit of perspective on this?

Yes I can!

Rust was originally a personal project of a Mozilla employee. At some point, Mozilla spun up an R&D division, and asked if people had projects they wanted to incubate. Rust and Servo were pitched to Mozilla as one of said projects, specifically to make a "generational leap" in web browser implementation. Management bought in, and both projects have been growing ever since.

I gave a talk for the ACM on Rust's early history that may interest you:

Hah, clicking on the link led me to the realization that I had already seen that talk before! But I keep getting amazed at how much Mozilla has invested into this project :)

Is there anything that was removed from the language that you'd like to bring back in some way (another form, different syntax, etc)?

Before Rust 1.0, we removed the ~str syntax for owned strings. I don't want that syntax back, but its immediate replacement was named StrBuf, which we changed to String shortly after. If I could go back in time, I'd keep StrBuf.

Also, here's a Rust closure: || {} Here's a Ruby closure: {|| }

Given that we took the syntax from Ruby, I kind of wish we'd kept it identical; it gets very confusing when I switch back and forth.

I miss two things from the old days. First, we used to have an anonymous record syntax, where you could just write let point = {x: 1, y: 2}; (I think that was the to define a point without having to declare the type. We then could write json serializers that would transparently render that record out into a json object. Second, sometimes I miss our old closure syntax, which we stole from Ruby. We could write let x = |item| { item + 1 }. It would have made it easier to have pseudo-control flow methods.

Would you choose to live forever (assuming you are invulnerable and keep your current health)? Even if that means that you exist at and beyond the heat death of the universe?

Currently Rust is very slow to create some prototypes. Are there some IDEs with better support for creating Rust projects? Also some better intellisense would come handy.

Currently, VS: Code with the Rust plugin and IntelliJ have the best support. They're both under heavy development and improve rapidly!

Zermelo鈥揊raenkel set theory or homotopy type theory? Or should we accept pluralistic view for foundation of mathematics instead?

ZF for me, thanks.

About error handling.. Let's say i'm a crate creator. For now recommended strategy for error handling is to make own error type:


and wrap all possible error with it.

Let's say someones uses my crate and he/she also need to wrap around my error with its own error type. Now when error occurs in 'ending' crate then there is a chain of converting errors, like:

std::io::Error > some-lib1 > some-lib2 > ..

which a lot of conversion is made + a lot of wrapper code is needed

Is there a way of doing it better?

Which game is better: Rust or Go?

Super Mario Odyssey.

(I kid, but there's also a deeper truth here; Rust loves to say "X vs Y? We don't choose, the real answer is Z." This is true with things like "Safety vs performance" or "Systems vs usability")

Why don't rust compiler warn when doing multiple imports?

use piston_window::*;

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.)

Is Rust used in any of geospatial operations? Kakadu for jpeg2000 is written in C++. Do you have some benchmarks where Rust could outperform C++?

Is Rust used in any of geospatial operations?

This is not my area of expertise.

Kakadu for jpeg2000 is written in C++. Do you have some benchmarks where Rust could outperform C++?

I'm always wary of linking to the benchmarks game, as microbenchmarks are, well, microbenchmarks, but

As you can see, we're faster sometimes, slower sometimes. One area where Rust is significantly slower are the ones where we need explicit SIMD; that's coming to stable Rust soon, but not quite yet.

In general though, there's some other ways to think about this question that are interesting: Rust has significantly more information about the code at compile time than C++ does, especially around things like pointer aliasing. We're not properly using that information for performance yet, but once we do, we should see some big speedups.

Another way is "safety doesn't make you slow, it lets you go fast." Several big Rust users, such as the Stylo team, have talked about how Rust's compile-time guarantees let them do very aggressive things that you can do in C++, but are irresponsible to do, because they're so tricky. There were actually two previous attempts to parallelize Firefox's CSS code in C++ before Stylo did it in Rust, and they both failed. I find this idea much more promising than microbenchmarks when talking about performance in both langauges.

Finally, there's also the question of "the best vs the best" and "the average vs the average." Even if C++ could squeak out more performance in the hands of an expert than Rust in the hands of an expert, the more compelling question, in my mind, is "how does the speed of the average C++ dev's code compare to the speed of the average Rust dev's code." In Rust, the fastest thing is often the easiest thing. Time will tell!

Is Rust used in any of geospatial operations?

Also not my area, but I do know there are a number of geospatial libraries in

I don't know enough about formal verification (or even if that's the right term), but do you guys see Rust making it relatively easy to verify that a program does what is supposed to do and only that? In time, does Rust have the potential to bring an even higher degree of program soundness than just memory and thread safety?

We hope so! We're currently working with academics to define and verify the language itself; once we do that, we'll see what the future holds :) It's on a long timeframe though.

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.

Yes, absolutely! We're actually working with a number of academic and industrial groups in this realm to uncover the potential there.

It's unclear whether this verification work will ever become part of the core language, or always remain an additional tooling layer. But regardless, the Rust type system provides, by construction, a lot of information that you otherwise have to work very hard to get via static analysis.

I'd expect to see some initial forrays here as early as 2018.

what about rust-lang for web-server (back-end webdev)? oh, I just now discovered : which address this topic.

Yeah, we also addressed this in several other questions; TL;DR is that this was a big focus of this year, and so stuff is moving along!

As an iOS engineer, why should I learn Rust?

Do your apps have some performance-critical or reliability-critical components? Rust may be the best and quickest way to build those components, while keeping the surrounding app in Swift/ObjC.

Hi Rust devs! I love your language, it is a great experience to code in. Got question about simple C++-like "std::cin" manipulation. Doing pretty advanced things on an online judge platforms are fairly straitforward except input handling in performant manner. On spoj for example you can't - as far as I know - use extern crates. What do you think about adjusting std lib or docs to simplify the process?

I haven't personally run into that need very much, so I can't speak to it directly. The best way to make this change is to get a crate going, prove it popular in the ecosystem, and then make a proposal.

Are deep learning or machine learning in rust a near future?

We've had several projects in this space, and a talk at RustConf last year:

TL;DR: there's some intrepid people working in this space, but it's early days.