Rust 2020

Compile-time constraints, ergonomics, and docs
The Rust logo with

Something, something, hindsight.

The end of the year is fast approaching and that, my friends, means that it’s time for a deluge of end-of-year Rust blogs. The Rust core team has put out a call for blogs to help decide where to take the language next, as they do every year. I’ve been quite invested in Rust for a few years now, so I thought it was about time I joined the fray.

Considering that I spend a disproportionately large amount of time thinking and reading about Rust compared to how much I actually use it, do take my thoughts and wishes here with a grain of salt; they may not be what the community needs the most, it’s just what I’d want in my ideal, little world.

Stabilize slice patterns (#![feature(slice_patterns)])

This is the one language feature I find myself wanting stabilized more than any other. Coming from languages like Haskell—and to a lesser extent Python and JavaScript—that have simple ways to destructure a list of values, doing this can feel quite clunky in Rust. Especially if all you want to do is get the head and the tail of a Vec or a slice. Yes, the split first function on slice does do that, but using it is tricky. In particular, how you handle destructured lists using case of statements in Haskell feels really ergonomic and intuitive to me.

Luckily, it seems we’re headed in that direction. There is a tracking issue for the slice_patterns feature on GitHub, and save for some remaining compiler issues, it should be about ready to go in. For now, you can check it out on the nightly channel with the feature toggle #![feature(slice_patterns)].

What’s more, because rust matches on slices and not linked lists like in Haskell, we get some extra goodies, such as being able to extract not only the first n items, but also the last m items. Here’s a little playground link that I put together demonstrating some cool uses for slice patterns. (Note: you probably can do this in Haskell somehow—a little bit of searching tells me the ViewPatterns compiler extension might do the trick—but it’s not baked into the base language like this.)

Easy async (documentation!)

I was holding a Rust workshop for some colleagues recently and one of them asked me to create an example of how you’d fetch web data using Rust. I thought this would be a great chance to have a little sneak peek at async/await before it stabilizes and get familiar with it: I figured I’d try and write a super simple application that fetches some data from an endpoint and dumps it to the terminal. However, I could not make it compile, and if it compiled, it didn’t run properly (presumably because the future was never started).

What I’d like to see is more information on how to do basic async programming in Rust. The Async Book has a chapter on it, but I still find it confusing with all the different traits and unstable features. I’ve tried following the example with the Hyper server to make a request, but I keep running into trait bound errors. I’m sure if I sat down and spent some more time on it, it would work, but it feels like it’s missing that ‘get started in 2 minutes’ section.

I’m sure this will improve very quickly over the next few weeks with the stabilization of async/await, but for now it’s a hurdle.

Generic Associoted Types (GATs) and const generics

I’ve lumped these two together because I’ve not really followed either particularly closely, but reading up on them for the purpose of this post, I’m suddenly quite excited by both. In general I’m all for anything that makes the type system more expressive and allows us to create more compile-time constraints.

GATs
Const generics

In summary

I already had some ideas in mind, so I thought writing this post would be quick and easy, but I ended up diving down multiple rabbit holes, and in the end it took much longer than expected. That said, I learned a lot along the way, and I’m even more excited about the language and where we’re headed now.

Apart from this short wish list, I also think it’s important that we stay aware of the community and keep them in mind. As has been mentioned in a number of other blogs, let’s try and make Rust sustainable for everyone: maintainers, core team, working groups, and community members alike. Let’s also try and move forward with game development, GUI development, and web development. We’re already great. Now let’s be even better. And no matter where we go from here, I’m confident that as long as the community stays warm, welcoming, and inclusive, we’ll have something to be proud of.

Much love ❤️