The Nature weekly journal of science was first published in 1869. And after one and a half century, it has finally completed one cycle of carcinization, by publishing an article about the Rust programming language.

It’s a really good article.

What I liked about this article is that it didn’t just talk about performance, or even just memory safety - it also talked about correctness.

Good morning! It is still 2020, and the world is literally on fire, so I guess we could all use a distraction.

This article continues the tradition of me getting shamelessly nerd-sniped - once by Pascal about small strings, then again by a twitch viewer about Rust enum sizes.

This time, Ana was handing out free nerdsnipes, so I got in line, and mine was:

During a recent Rust Q&A Session on my twitch channel, someone asked a question that seemed simple: why are small string types, like SmartString or SmolStr, the same size as String, but small vec types, like SmallVec, are larger than Vec?

Now I know I just used the adjective simple, but the truth of the matter is: to understand the question, we’re going to need a little bit of background.

Learning Rust is… an experience. An emotional journey. I’ve rarely been more frustrated than in my first few months of trying to learn Rust.

What makes it worse is that it doesn’t matter how much prior experience you have, in Java, C#, C or C++ or otherwise - it’ll still be unnerving.

In fact, more experience probably makes it worse! The habits have settled in deeper, and there’s a certain expectation that, by now, you should be able to get that done in a shorter amount of time.

As I’ve said before, I’m working on a book about lifetimes. Or maybe it’s just a long series - I haven’t decided the specifics yet. Like every one of my series/book things, it’s long, and it starts you off way in the periphery of the subject, and takes a lot of detours to get there.

In other words - it’s great if you want an adventure (which truly understanding Rust definitely is), but it’s not the best if you are currently on the puzzled end of a conversation with your neighborhood lifetime enforcer, the Rust compiler.

I used to be afraid of async Rust. It’s easy to get into trouble!

But thanks to the work done by the whole community, async Rust is getting easier to use every week. One project I think is doing particularly great work in this area is async-std.

Let’s say we want to compute the SHA3-256 hash of a file. It’s very easy to do with synchronous I/O:

I write a ton of articles about rust. And in those articles, the main focus is about writing Rust code that compiles. Once it compiles, well, we’re basically in the clear! Especially if it compiles to a single executable, that’s made up entirely of Rust code.

That works great for short tutorials, or one-off explorations.

Unfortunately, “in the real world”, our code often has to share the stage with other code. And Rust is great at that. Compiling Go code to a static library, for example, is relatively finnicky. It insists on being built with GCC (and no other compiler), and linked with GNU ld (and no other linker).

I started experimenting with asynchronous Rust code back when futures 0.1 was all we had - before async/await. I was a Rust baby then (I’m at least a toddler now), so I quickly drowned in a sea of .and_then, .map_err and Either<A, B>.

But that’s all in the past! I guess!

Now everything is fine, and things go smoothly. For the most part. But even with async/await, there are still some cases where the compiler diagnostics are, just, so much.