@aturon
Rust core team
Nothing here yet.
Nothing here yet.
No blogs yet.
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.
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).
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.
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.
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!
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.
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.
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 .