Category: Rust

Today is day 3 of the GNOME+Rust hackfest in Mexico City at the beautiful new Red Hat office. We’ve been working on all sorts of stuff since we were graced with the presence of a few Rust hackers from Mozilla Research.

In particular, Niko and Federico have been working on a GObject plugin for Rust that allows us to have a nice, almost Vala-esque, syntax for writing GObjects. It’s pretty exciting to watch a compiler hacker at work. After lots of talks about GObject design internals, performance hacks, re-entrancy protections, and more, I think we’re headed down a solid path to enabling our Object Oriented style of development, but from Rust.

In addition to playing the code historian, I spent some time trying to get Builder’s support for the Rust Language Server up to snuff. It’s still a bit annoying to get rls installed¹, but it sounds like RustUp will support it soon which means we can make it seamless. Anyway, I fixed a bunch of little bugs that cropped up in the recent months as both Builder and rls projects churned like crazy.

I also implemented support for “Find all References” last night. In a Rust document, just Constrol+Shift+Space to get the list of references, followed by up/down, and return to jump. I’d like the IdeSymbolResolver’s for Clang and Vala to support this soon too.

¹ To install rls, start by installing the nightly toolchain from Builder’s Preferences → SDKs. If you’ve not done this before, you’ll need to first click the “Install” button for RustUp. Then add a new Rust Toolchain called “nightly” and set it as the default. Clone the rls repository and run ~/.cargo/bin/cargo install from within that project. The good news is we should be able to simplify this quite a bit in the near future.

Thanks to Georg Vienna, Builder can now manage your Rust installations using RustUp!

With Federico’s wonderful post on Rust’ifying librsvg I guess it makes sense to share what I’ve been doing the last couple of days.

I’ve been keeping my eye on Rust for quite a while. However, I’ve been so heads down with Builder the last two years that I haven’t really gotten to write any or help on integration into our platform. Rust appears to take a very pragmatic stance on integration with systems code (which is primarily C). The C calling convention is not going anywhere, so at some point, you will be integrating with some part of a system that is “C-like”. Allowing us to piecemeal upgrade the “Safety” of our systems is much smarter than rewrite-the-universe. This pragmatism is likely due to the realities of Rust’s birth at Mozilla. It’s a huge code-base, and incrementally modernizing it is the only reality that is approachable.

We too have a lot of code. And like many other projects, we care about being language agnostic to a large degree. In the early days we might have chosen C because it was the only toolchain that worked reliably on Linux (remember C++ pre-2000? or LinuxThreads?) but today we still care about “Language Interopability” and C is the undeniable common denominator.

One way in which we can allow the interopability that we desire and the Safety we need is to start approaching some of our problems like Federico has done. The C calling convention is “Safe”. That is not where zero-day bugs come from. They come from hastily written C code. It is perfectly fine to write our interfaces in C (which can be our basis for GObject Introspection) but implement Safety critical portions in Rust.

This is exactly what I’d like to see from the hundreds of thousands of lines of C I’ve written over the years. We need to identify and fix the Satefy Critical portions. GStreamer is already on the right track here by looking at codec and plugin implementations in Rust. I’m not sure how far they will go with adapting to Rust, but it will be one of the best case-studies we will have to learn from.

So because of this desire to look at building a Safer Platform for developers and users alike, I’ve decided to start adding Rust support to Builder. Thanks to the hard work of the Rust team, it’s a fairly easy project from our side. There is a new Language Server Protocol 2.0 that was worked on by various people at Microsoft, Red Hat, and elsewhere. The new rustls was announced last week and uses this protocol. So I implemented support for both as quick as I could, and now we have something to play with.

Because of the Language Server Protocol, our Rust plugin is tiny. It is essentially a glorified supervisor to handle subprocess crashes and some binding code to connect our stdin/stdout streams to the Language Server Protocol client in Builder. See for yourself.

There is a bunch more work for us in Builder to make it a great Rust IDE. But if people start playing with the language and are willing to work on Builder and GNOME to improve things as a community, we can build a Modern, Safe, and Elegant developer platform.

The big ticket next steps for those that want to contribute to Rust support would include:

• Cargo build system support. I do believe that ebassi started on something here. But I need to circle back around and sync up.
• Symbol Tree needs improvements.
• Semantic highlighter (which we can implement using fuzzy symbols from the symbol tree until a real protocol comes along).
• Upstream rustls needs work too to get us the features we want. So Rustaceans might want to spend some time helping out upstream.
• We need to simplify the glue code from Rust←→GObject so that it is dead simple to wrap Rust code in a GObject-based library (where we get our free language interopability).
• … and of course all the other Builder plumbing that needs to happen in general. See our list of projects that need work.