I got back from Rustconf 2023 last week, and I had a great time! I thought I'd write up my impressions of the conference, for anyone curious about what it's actually like.
Hi! Just a quick note to say that I'm going to Rustconf this year. If you're going too, let me know (see the about page for contact details) and I'd love to say hi. I'm always down to meet new people, so consider this an open invitation to anyone at Rustconf.
I don't pair program very often, but sometimes when you're stuck on a really annoying problem, it can be helpful to have a coworker looking over your shoulder. My new job is fully-remote, so we occasionally screenshare when someone's stuck. One of my favourite things about pair programming is that I get to see the little idiosyncracies of everyone's workflow. For example, you notice which peers use vim for everything, and pick up on all their awesome little keybindings to jump around the document. Or you realize that one peer has installed a bunch of awesome VSCode extensions that you can steal.
Several coworkers have remarked that I use shell aliases way more often than them! For example, I mostly work with rust, so I used
alias c="cargo" to tell my shell "when I type
c, replace it with
cargo". Then I use Cargo's built-in aliases, e.g.
cargo check and
cargo c are equivalent. So, when I want to run
cargo check I just type
c c and my shell expands it to
cargo c and Cargo expands it to
cargo check. My coworkers were very amused by this! I think a suite of nice, easy aliases can really save you time and avoid interrupting your flow state. I'm trying to use more aliases for common tasks, and here's how I've been doing it.
Multipart, or "form-encoded data", is something I see everywhere but never had to actually understand or use myself, because HTTP libraries handled it for me. Recently, though, I had to dive deeper into how multipart works, because it's pretty important at both Cloudflare and my new job at KittyCAD. Used correctly, multipart makes your file uploads faster and use less memory. I'm going to explain how it works, at a high level, so you'll recognize when you could use it to save time and memory in your HTTP servers/clients.
I read and liked Andrew Israel's I love building a startup in Rust. I wouldn't pick it again. It makes a lot of sense! He basically says that his startup prioritizes developer productivity over performance. Sensible choice for a start-up founder to make. If Rust is going to slow your developers down, and you don't need its benefits, then you should definitely consider using a different language.
On the other hand, I've been using Rust as high-level language at Cloudflare for a few years now. By "a high-level language" I mean one where performance doesn't really matter much. I've mostly been using it for API servers, where overall latency doesn't really matter too much. I'd be totally fine using a garbage collected language, or an interpreted language, because I don't need to eke out every last microsecond for blazing fast performance. I just want my server to stay up, do its job, and let me ship features quickly.
So why use Rust for a task like that? Well, although Rust has a reputation for being a low-level systems language, it actually does an admirable job of acting like a high-level language. So here's my list of reasons to consider using Rust, even for a project where performance isn't critical.
Hi all! Allen Wyma of Rustacean Station had me on the podcast to talk about Rust at Cloudflare. We cover why and how Cloudflare started using Rust, how my team specifically works with Rust, and how Cloudflare works. We also go on a big tangent about social security numbers. Give the episode a listen if you'd like.
Say you're running a long-lived program, like a server. Let's say the server needs to read some files from disk, like certificates or keys. Every so often, the certificates change, so your server has to reload them. How do you tell the server to reload those files? The traditional way is to use Unix signals. Your server listens for a particular signal, like
SIGUSR1 (user-defined signal #1) or
SIGHUP (hangup signal), and can execute whatever code you programmed in when the signal is received. So, your code waits for the appropriate signal, receives it, then reloads the certs.
This approach works fine, but it has some usability problems that came up at work. So, my coworkers have been thinking about better ways to do this. I wanted to blog about one such way, and see if anyone has better ideas.
Reflecting on the things I liked in 2022. I started writing this in December 2022 and completely forgot to finish it until February next year.
In case you didn't hear, comedy is now legal on Twitter but accounts engaged in parody must include “parody” in their name, not just in bio. Of course, this only made everyone double down. So yesterday, I changed my name to Rust Language and started posting misinformation.
The last week on twitter has basically been "the new 3rd grade substitute teacher can't control the class" and we're all misbehaving. I've changed my twitter back to my real name and face, so I've preserved my fake Rust tweets for posterity here.
I first learned Kubernetes ("k8s" for short) in 2018, when my manager sat me down and said "Cloudflare is migrating to Kubernetes, and you're handling our team's migration." This was slightly terrifying to me, because I was a good programmer and a mediocre engineer. I knew how to write code, but I didn't know how to deploy it, or monitor it in production. My computer science degree had taught me all about algorithms, data structures, type systems and operating systems. It had not taught me about containers, or ElasticSearch, or Kubernetes. I don't think I even wrote a single YAML file in my entire degree. I was scared of ops. I was terrified of Kubernetes.
Eventually I made it through and migrated all the Cloudflare Tunnel infrastructure from Marathon to Kubernetes. I didn't enjoy it, and I was way over my deadline, but I did learn a lot. Now it's 2022, and I'm leading a small team of engineers, some of whom have never used Kubernetes before. So I've found myself explaining Kubernetes to them. They seemed to find it helpful, so I thought I'd write it down and share it with the rest of you.
This article is aimed at engineers who need to deploy their code using Kubernetes, but have no idea what Kubernetes is or how it works. I'm going to tell you a story about a junior engineer. We're going to follow this engineer as they build a high-quality service, and when they run into problems, we'll see how Kubernetes can help solve them. Hopefully this will get you comfortable building your own services in k8s!