Kenny Kerr posted My Rust adventure begins this morning, and I tweeted "This seems like a pretty big deal - Rust is uniquely able to bridge the gap between performant systems programming and the safe, high level abstractions needed to build applications." This was a strong statement, and sparked a little discussion, so I'd like to clarify a bit.
The main controversy was about whether Rust is truly unique in this regard, or whether other languages can possibly satisfy the requirement of being a solid foundation for operating systems while also avoiding the pitfalls of C and C++. I argue that this role requires a language to be suitable for a very wide range of problem domains. Latency-critical applications such as pro audio are a fairly minor niche, and the vast majority of things people do at computers don't require that kind of low-level control, but if supporting, say, pro audio is one of the requirements, it basically excludes all GC'ed languages. VR probably doesn't require as strong a real-time guarantee, but nobody working in VR wants to leave milliseconds of latency or jitter on the table. (You also want to minimize FFI overhead when calling into the GPU, a major reason game engines are basically all in C++, even if there's a scripting layer in some other language)
Of course, making the foundations solid for performance-critical work will also have benefit for less critical applications. If your input pipeline, graphics compositor, and so on are all written in a performant way, then scrolling in your text editor and web browser will also be less janky.
My argument here is very similar to Bryan Cantrill's talk from a year ago, Is It Time to Rewrite the Operating System in Rust?. Again, the focus here is on foundational layers and the operating system itself, not on applications. I won't try to summarize the talk here, but people have been trying to replace C with higher level languages for many years, and even C++ brings with it enough problems to create friction at those lower levels. Bryan feels that Rust is one of the very few languages competent at the low levels to be a worthy successor to C in that space.
But now let's look at what Rust can bring to Windows specifically. I've been doing a fair amount of Rust Windows programming for years, first on xi-windows, now on druid, so I can speak from some experience. Windows itself has a long history of trying to move past C++, notably a huge investment in .NET and related technologies (CLR, C#). (Kenny's The road to Windows 8 is a great read). While C# is a great language for building applications, especially on Windows, it's fair to say it has not completely supplanted C++, either for building the operating system itself, or for building apps where performance is important - web browsers, photo editors, audio workstations, etc. Let's also not forget game engines, which I think was a pretty major area of investement.
The good news is that COM and Rust are already a reasonably decent impedance match. The reference counting semantics of COM are similar to Arc in Rust, so mostly what's needed are safe wrappers. Here, things are not quite so easy, because to do things really safely requires documenting things like whether a given method can be called from multiple threads. But if there's a concerted effort by Microsoft here, as opposed to amateurish wrappers, I think it can pay off nicely, with greatly improved reliability of the final system. And, I strongly believe, that having to write down the correct Rust type is a fantastic way to improve the design of new COM interfaces - it's very likely that many of the instances I've found it tricky to come up with safe Rust wrappers are also rich sources of bugs for C++ consumers of these interfaces as well. (A good discussion of COM safety is an issue on com-rs)
I'm not saying that Rust should be used for everything - it shouldn't. For many applications, other languages will be better choices, not least of which is the learning curve for Rust. But for this kind of foundational systems work, I do think it can bridge the gap between low-level performance considerations and high-level expressivity. And, exactly because it has such a thin runtime of its own, it is also exceptionally well suited for binding to managed languages. In other words, it is potentially another path to achieving the goals of the CLR, without requiring "one runtime to rule them all."
And if Rust is available as a viable, first-class supported choice for writing applications such as that music workstation that doesn't crash often, or the vector graphics editor that doesn't take forever to launch, that makes me happy also.
So I'm really happy to see these explorations into Rust, and excited to see where it all goes.