Chris Holdgraf:

My guiding principle for using BlueSky (or any platform or SaaS product for that matter) is to assume that it will go away in three years. It’ll either go bankrupt, get bought, or change its strategy to enshittify the product. You can make an argument that BlueSky has some technical protections against this [..] but I think the heuristic above is still the right one to follow.

So I’m going to try treating BlueSky as a temporary place to make connections or share ideas, but do my best to direct attention, deeper thoughts, “real” value to places that I have more control over.

I’ve been banging the own your identity drum for a long time now and this post contains a lot of sensible suggestions. The ultimate in owning you content and identity is self-hosting but this post contains suggestions that don’t require that level of complexity.

In other words: don’t build your castle in a kingdom that somebody else controls, because they can take it away from you. Instead, build a castle on defensible land, and leverage platforms to bring more ideas, people, value, etc to your castle.

This is similar to the IndieWeb POSSE concept: Publish (on your) Own Site, Syndicate Elsewhere. See also micro.blog.

Rather than treating BlueSky content as persistent (and thus referenceable in things like blog posts or papers), I’ll try rendering conversations into a static form before including them in my writing.

This is a good point, I almost got bit by this with my self-hosted Pleroma instance when it came time to retire it. I was able to work around it by creating a static archive of my content.

Rather than sharing BlueSky links in “learn more about me” slides etc, I’ll lead with links to my website.

Not that I do slides very often, but a short personal domain (wezm.net) has turned out handy for this.

Not everything needs to be persistent over long timelines!

This is the pragmatic choice, but I think people are far too willing to break links on the internet. With a bit of care, redirects and static archives can keep links up for years to come.

Simon ‘icefox’ Heath:

In case you missed it, there’s a whole new generation of low-level programming languages being created right now. Rust demonstrated vividly in 2016 that there is a massive unmet need in this space, and it has spawned a bunch of successor languages, though none of them have really hit the relative big-time like Rust has. I’m one of those programmers that has spent 20 years or so asking “can we PLEASE do low-level code in anything besides C and C++?” so I wanted to take an actual look at the languages I know about and do a bit of compare-and-contrast.

This is an opinionated take, and honestly not a particularly deep one, since I don’t know most of these languages and I don’t want to spend months researching each one. I’m also not gonna quibble about what is and is not low-level. I’m moving long-distance soon, and my brain needed something interesting and productive-feeling but not terribly deep, so I’m gonna spend a max of a day or two on each language. I’m gonna give a little bit of history but confine my opinions to the actual languages rather than the whole ecosystem and tooling around them, and just go down the list in chronological-ish order. While very important, tools are far more mutable and easier to change.

Exactly what it says on the tin. If you’d like a quick, opinionated survey of languages in the systems language space, this post makes for a great read. Aside from the commentary it also serves as a good reference of languages to check out of you’re looking for a language for lower-level work.

CodingFont is a neat way to choose a monospace programming font. You’re presented with code set in a pair of fonts and must pick the one you prefer. After each round new pairs are drawn from the remaining fonts until you end up with an ultimate winner.

I ended up with JetBrains Mono, which is a fine choice for me given the options. Notably Iosevka and my personal favourite, PragmataPro were missing though.

On my personal blog:

I added caching so that the application only renders a page once. After that, the cached render result is reused for subsequent responses. These cached responses are typically generated in about a third of a millisecond (~323µs on average), which I was pretty happy with.

The problem was, for my convenience the server hosting Linked List was located in Australia, where I live. Unfortunately most other people do not live in Australia, and we’re a long way from everywhere.

A bit of behind the scenes information on how I built a tiny CDN for Linked List by adding some cheap additional servers orchestrated with pyinfra.

Joe Warren:

Christmas Ornaments based on programming language logos.

Generated using Haskell & Waterfall CAD

For all your nerdy 3D printable Christmas decoration needs. New logos are still being added. Since I first saw the repo Terraform, BigQuery, Python, Snowflake, Go, Rust, and Ruby have been added.