Last time, I set out to build a Result<T, E> type in Kotlin, and discovered some awkwardness around parameterizing the types of the variants. This issue, I realize I totally forgot about covariance, which significantly mitigates the awkwardness.
edit: I made a mistake in this article! See Covariance in a Result<T, E> type in Kotlin for corrections.
Kotlin provides a mechanism for sum types in the form of sealed classes. It works by closing the class for extension outside the immediate context, allowing the compiler to know every possible subtype and perform the exhaustive checking expected of the variants of a sum type. However, some typical sum type use cases are a touch awkward with this approach. Let's explore by trying to write a Result<T, E> type in Kotlin using a sealed class.
edit: Don't do this! Do this instead. Only read this article if you're looking for context.
Starting in Buster, Debian enabled the subpixel hinting functionality in Freetype (commonly known as the “Infinality” patches, though the enabled functionality is a small, more performant subset of the patches actually submitted by Infinality). To no one's greater surprise than my own, this badly broke my font rendering. Here's how I fixed it.
The Thinkpad X62 is a “restomod” of the well-received Lenovo Thinkpad X61 (produced in 2007) with a replacement motherboard and components, and usually a display upgrade, in the original case and keyboard. It's an interesting exercise in combining the lost positive attributes of older hardware (high-quality keyboard, 4:3 screens, comfortable surfaces) with some of the gains from newer hardware (faster components, broader and newer hardware standard support). I've been using one as my primary laptop since 2018, and these are my thoughts about it.