Mon, Apr 18, 2016
As touched on in a recent post about redoing this site, I recently had the (mis)fortune of using a Golang project in anger for the first time. It’s not exactly a reasoned critique drawn from years of experience, but I wanted to share some of my gripes regardless. As a long-time Python-using dev & sysadmin, I found the following things frustrating when attempting to use, troubleshoot, understand and/or modify a Golang project (specifically Hugo, but most would apply to anything in the ecosystem): Adding a build step to the development process: even a fast build step feels like pulling teeth when one’s used to a simple edit-save-run cycle; and Hugo currently takes about 5-10 seconds (!) to build on my no-slouch workstation, even with all its dependencies cached. Complete lack of built-in dependency version metadata: simply inexcusable for a language developed in 2009. Third party solutions exist, but are far from widely used. This makes debugging specific versions enormously frustrating if anything in the dependency tree ever breaks backwards compatibility. (Surprise: that happens frequently!) Plan 9 CLI flags: also inexcusable for such a new language. Sure, let’s use obscure -os -nobody -uses -style instead of what --literally --everyone --else -d -o -es.

Mon, Apr 18, 2016 | personal

I’ve rebuilt my website! This post isn’t likely to be interesting unless you’re into static site generators or navel-gazing. It’s also not too long, as I’m omitting almost all the gory details.





Sun, Sep 29, 2013 | documentation, maintainership, sphinx

Most open source projects store documentation in the source repo itself. This is easy to do, allows the doc builder to reference in-code documentation (like Python docstrings), makes contributions from others simpler, etc.

However, it doesn’t always play nice with “meta” information such as how to contribute, project roadmap, and so forth.





Fri, Jul 26, 2013 | announcements, fabric, paramiko

Deciding when to release software can be difficult. Releasing after every patch or merge is typically too much, though some argue otherwise: it depends how you define “often” in “release early, release often”.

The other options are “whenever you feel like it” and “have a specific schedule”.

Until now I’ve always gone with that middle option, waiting until a large-enough set of changes had piled up to merit a new release.