The past few years I've seen more projects use Go or Rust for heavy lifting alongside a higher-level language like PHP or JavaScript.

I've learned a little Go myself but don't know enough about Rust to understand when you'd choose one over the other. Vercel is currently migrating a codebase from Go to Rust, it's interesting to read the reasoning behind the decision.

For example:

Go's preference for simplicity at the filesystem was creating problems for us when it came to file permissions. Go lets users set a Unix-style file permission code: a short number that describes who can read, write, or execute a file.

While this sounds convenient, this abstraction does not work across platforms; Windows actually doesn't have the precise concept of file permissions. Go ends up allowing us to set a file permission code on Windows, even when doing so will have no effect.

In contrast, Rust's explicitness in this area not only made things simpler for us but also more correct. If you want to set a file permission code in Rust, you have to explicitly annotate the code as Unix-only. If you don't, the code won't even compile on Windows. This surfacing of complexity helps us understand what our code is doing before we ever ship our software to users.

Next to PHP, Go is a low-level language—but Rust is even lower. Looks like Go is great for heavy lifting on the web, but if you're into building tools to run in different environments Rust is where you want to be.

Neither here nor there, but a PL/pgSQL function for redacting emails in Postgres to derisk leaking PII.

Now, with the World Congress out of the way, it is time to focus on my new role as Director of Developer Relations at WeAreDevelopers. It feels great that what I do anyways because of personal interest is part of my role. This was the case when I worked for Yahoo and Mozilla and the […]

I used to leave pull request descriptions empty. "Let the code speak for itself" or "let the commits speak for themselves" are the perfect getaway from the extra work of documenting your thought process.

Recently, I've experienced that spending time on a good description is a worthwhile investment.

Notes to self

If you're working on a feature that takes a few days to complete, open a draft pull request as soon as possible. Keep the description up to date as you move forward.

When the rabbit hole of your fix or feature turns out to be deeper than expected, you'll have left a bunch of breadcrumbs behind you to trace back your steps instead of running in circles.

Besides describing what you've done, document next steps too. If a more pressing bug or features comes up and you need to leave the PR alone for a few days (or months), it'll be easier to get back in it with an actionable to-do list.

Happy reviewers

Reviewers are happy to have a summary for a high-level overview. Odds are the description might also answer some questions that would come up in the review ("why didn't you do it this (other) way?"). Less back-and-forth communication speeds up the review process.

During the review, keep the description up to date. Don't only rely on comments. Future readers shouldn't need to dig through a thread to get the gist of the decisions made.

Some extra context for the next developer (or future you)

Not all documentation has to be prose. Commits are documentation. Issues are documentation. Support articles are documentation. Pull requests are documentation. No need to put all your eggs in one basket. Pull request descriptions aren't a replacement for a structured document, but they're a welcome extra.

There's a 90% chance no one will read your debrief after the code is merged. But in the off-chance someone does, they'll be grateful it's there.

And while reading through git history tells you how the feature was implemented, it doesn't provide any context on how it wasn't implemented.

The actionable part: how to get started

At the end of the day, make sure:

• There's an open (draft) pull request
• The pull request has a description
• The description is up to date

Start doing this for pull requests that live longer than a day, that's where descriptions are most valuable. Before you know you've built a new habit.

What else happened this week? Well, I wrote my first op-ed; also, I got some mail.