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.

Hey everyone!

This article is brought to you by a shameless nerd snipe, courtesy of Pascal.

In case you’ve blocked Twitter for your own good, this reads:

There should be a post explaining and comparing smolstr and smartstring (and maybe others, like smallstr)

Well, I took the bait.

But, since this is me writing, I get to set the rules:

• There will be no “maybe others” - we’ll review just the first two

Since I write a lot of articles about Rust, I tend to get a lot of questions about specific crates: “Amos, what do you think of oauth2-simd? Is it better than openid-sse4? I think the latter has a lot of boilerplate.”

And most of the time, I’m not sure what to responds. There’s a lot of crates out there. I could probably review one crate a day until I retire!

I’ve been banging the same drum for years: APIs must be carefully designed.

This statement doesn’t resonate the same way with everyone. In order to really understand what I mean by “careful API design”, one has to have experienced both ends of the spectrum.

But there is a silver lining - once you have experienced “good design”, it’s really hard to go back to the other kind. Even after acknowledging that “good design” inevitably comes at a cost, whether it’s cognitive load, compile times, making hiring more challenging, etc.