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.

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.

Read more

One of my favorite underrated (and underused!) CSS properties is font-variant-numeric: tabular-nums.

Tabular numbers are monospaced, which keeps their sizes consistent and keeps numbers with the same amount of digits aligned.

There are two common cases that warrant tabular numbers: tabular data and moving numbers.

Read more

A lesser-known piece of Markdown syntax (and HTML) are description lists. Description lists are great for small bits of "key-value"-like information.

Read more

Apparently Frank Herbert's Dune can teach us lessons on product management:

Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: "Now, it's complete because it's ended here."

(I haven't read the book yet, but would love to one day!)

I enjoyed Mohamed's post on using PHP and Go to have the best of both worlds.

By employing a polyglot architecture, we get the best of both worlds. PHP provides the development speed required to compete in a hyper-growth market, while Go provides more efficient resource utilization.

Another good quote from the introduction of his PHP to Go course:

PHP may be slow and memory hungry when compared to a compiled language, but that's not a result of a bad design.

It's like this by design because of all the choices it makes on your behalf to conceal complexity.

I also recommend his post on Twitter about the business decisions behind cutting costs on infrastructure.

A few years ago we built a tiny web tool to view a site's DNS records. I still use it on a regular basis when I need to do a quick lookup.

Some cool tidbits:

• Visit dnsrecords.io/{domain} to jump straight to the results (great for a Raycast/Alfred workflow!)
• Type ip or visit dnsrecords.io/ip to display your current IP address
• When you share a link to dnsrecords.io/{domain}, it will display the records in the meta & open graph descriptions

I've attended this talk twice this year and it hit just as hard the second time. Happy to see it available online. Start watching already!

A short & sweet overview of get(), cursor(), chunk(), and lazy() to retrieve models from the database. It's a tradeoff between speed and memory usage.

Just a Twitter account I've been enjoying lately. Small worlds posts a tiny sci-fi story every day (with lovely visuals!)

Follow @smllrworlds on Twitter.

When building a CRUD interface in an event sourced system, you'll come across the dilemma of how granular your events should be. Should you have a large PostUpdated event, or granular TitleUpdated, ContentUpdated, and AuthorUpdated events?

Read more

Personal websites are often blogs these days: a chronological stream of thoughts, news, and articles. However, some content is worth more than a post stuck and lost in time.

If I need to publish content about an emerging API, I need a couple of things. I need reference documentation so that people who want to try it out understand how to use it. This reference is evergreen content, and I will update it as the API changes. It is helpful to have, right up front, information about the last time we updated the content and the version of the spec, or browser to use for testing. I also want to let people know that we’ve shipped this experiment, so I need a news post pointing to my reference material, explaining that this thing is here, and asking people to try it out and give us some feedback. I will not update the news post; what I might do, however, is write another news post when the spec and implementation changes to let people know the progress. These news posts are my paper trail.

Food for thought for my own site. I have a bunch of old articles I wish were more discoverable as pages outside of the "blog" format.

At Laracon US we announced we're working on a new course at Spatie: Full Stack Artisan.

In Full Stack Artisan, we'll dive into building Laravel applications with Inertia, React, TypeScript, view models, our Laravel Data package, and more.

Last week I took a break from working on course content to set up branding and a landing page.

Read more

Jeremy Keith has an interesting take on how AI affects how we interact with search engines as content creators.

Previously, Google had a mutually beneficial agreement with websites: websites provided content, and Google brought traffic. Now, Google is using our content to generate and host their own.

What a lovely project! Project E-Ink builds a large e-ink display that displays the front page of the newspaper.

I have a strong attraction towards e-ink. I think it's because despite being state of the art technology, e-ink doesn't feel "digital". In the case of this display: it's there, it's connected, but it's static. It's up to date but doesn't grab your attention.