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.
Lies we tell ourselves to keep using Golang
In the two years since I’ve posted I want off Mr Golang’s Wild Ride, it’s made the rounds time and time again, on Reddit, on Lobste.rs, on HackerNews, and elsewhere.
And every time, it elicits the same responses:
- You talk about Windows: that’s not what Go is good at! (Also, who cares?)
- This is very one-sided: you’re not talking about the good sides of Go!
Futures Nostalgia
Up until recently, hyper was my favorite Rust HTTP framework. It’s low-level, but that gives you a lot of control over what happens.
Here’s what a sample hyper application would look like:
$ cargo new nostalgia
Created binary (application) `nostalgia` package
$ cd nostalgia
$ cargo add hyper@0.14 --features "http1 tcp server"
Updating 'https://github.com/rust-lang/crates.io-index' index
Adding hyper v0.14 to dependencies with features: ["http1", "tcp", "server"]
$ cargo add tokio@1 --features "full"
Updating 'https://github.com/rust-lang/crates.io-index' index
Adding tokio v1 to dependencies with features: ["full"]
Request coalescing in async Rust
As the popular saying goes, there are only two hard problems in computer science: caching, off-by-one errors, and getting a Rust job that isn’t cryptocurrency-related.
Today, we’ll discuss caching! Or rather, we’ll discuss… “request coalescing”, or “request deduplication”, or “single-flighting” - there’s many names for that concept, which we’ll get into fairly soon.
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.