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.

We've had several projects in this space, and a talk at RustConf last year: https://www.youtube.com/watch?v=lY10kTcM8ek

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

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.

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.

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. https://www.neon-bindings.com/ 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.

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: https://www.youtube.com/watch?v=79PSagCD_AY

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

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!

https://github.com/ctjhoa/rust-learning has a huge list!

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.

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!

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.

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.

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

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 benchmarksgame.alioth.debian.org/u64q/compare.php

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 crates.io.

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.

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 = array.map |item| { item + 1 }. It would have made it easier to have pseudo-control flow methods.

Hi! :D

I was visiting my family for Christmas back in 2012, and saw this on Hacker News: mail.mozilla.org/pipermail/rust-dev/2012-December…

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

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

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!

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.

Yes.

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 know Tau is "more right" but... Pi.