Articles
Articles are single-page pieces that give a whirlwind tour of a specific topic.
They’re different from series, which go very in-depth, taking many detours.
Surviving Rust async interfaces
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:
Thoughts on going down the network stack
So!
I have no shortage of ongoing writing projects - I still need to edit and publish the final parts of making our own executable packer, and I’ve recently announced I was working on a Rust book/series. Those are still both on the table.
Buuut… I’m also looking at other things. My best writing happens when I’m learning about something at the same time I’m writing about it. So for example, the Rust book is a bit harder to write, because I’m mostly trying to distill knowledge I’ve already absorbed (for the most part).
A dynamic linker murder mystery
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).
Getting in and out of trouble with Rust futures
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.
Small strings in Rust
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
Beware the Google Password Manager
Hey internet! So, someone broke into some of my accounts.
I’m taking entire responsibility for this - there’s the part where I fucked up, and if I didn’t fuck up, then none of this would’ve happened.
But there’s also the part where a series of design decisions from various vendors combined into the perfect storm for me.
And we’re going to talk about both! Separately! And calmly.
Image decay as a service
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!
Abstracting away correctness
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.