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.
A Rust match made in hell
I often write pieces that showcase how well Rust can work for you, and how it can let you build powerful abstractions, and prevents you from making a bunch of mistakes.
If you read something like Some mistakes Rust doesn’t catch in isolation, it could seem as if I had only nice things to say about Rust, and it’s a perfect little fantasy land where nothing ever goes wrong.
Some mistakes Rust doesn't catch
I still get excited about programming languages. But these days, it’s not so much because of what they let me do, but rather what they don’t let me do.
Ultimately, what you can with a programming language is seldom limited by the language itself: there’s nothing you can do in C++ that you can’t do in C, given infinite time.
As long as a language is turing-complete and compiles down to assembly, no matter the interface, it’s the same machine you’re talking to. You’re limited by… what your hardware can do, how much memory it has (and how fast it is), what kind of peripherals are plugged into it, and so on.
Profiling linkers
In the wake of Why is my Rust build so
slow?, developers from the mold and
lld linkers reached
out,
wondering why using their linker didn’t make a big difference.
Of course the answer was “there’s just not that much linking to do”, and so any
difference between mold and lld was within a second. GNU ld was lagging way
behind, at four seconds or so.
Why is my Rust build so slow?
I’ve recently come back to an older project of mine (that powers this website), and as I did some maintenance work: upgrade to newer crates, upgrade to a newer rustc, I noticed that my build was taking too damn long!
For me, this is a big issue. Because I juggle a lot of things at any given time, and I have less and less time to just hyperfocus on an issue, I try to make my setup as productive as possible.
My ideal Rust workflow
Writing Rust is pretty neat. But you know what’s even neater? Continuously testing Rust, releasing Rust, and eventually, shipping Rust to production. And for that, we want more than plug-in for a code editor.
We want… a workflow.
Why I specifically care about this
This gets pretty long, so if all you want is the advice, feel free to jump to it directly.
A terminal case of Linux
Has this ever happened to you?
You want to look at a JSON file in your terminal, so you pipe it into jq so you can look at it with colors and stuff.
That’s a useless use of cat.
…oh hey cool bear. No warm-up today huh.
Sure, fine, okay, I’ll read the darn man page for jq… okay it takes
a “filter” and then some files. And the filter we want is.. . which, just
like files, means “the current thing”:
Understanding Rust futures by going way too deep
So! Rust futures! Easy peasy lemon squeezy. Until it’s not. So let’s do the easy thing, and then instead of waiting for the hard thing to sneak up on us, we’ll go for it intentionally.
That’s all-around solid life advice.
Choo choo here comes the easy part 🚂💨
We make a new project:
$ cargo new waytoodeep
Created binary (application) `waytoodeep` package
What's in the box?
Here’s a sentence I find myself saying several times a week:
…or we could just box it.
There’s two remarkable things about this sentence.
The first, is that the advice is very rarely heeded, and instead, whoever I just said it to disappears for two days, emerging victorious, basking in the knowledge that, YES, the compiler could inline that, if it wanted to.