DEV-DIARIES
Dev Diary 2020-07-13
Today’s project was writing a command-line version of the CrushEntropy format. I like the ability to play around with relative time blocks in it, but there’s a few other features I’ve wanted (like “find the next free space for this thing”), and the ability to keep my calendars off-line and easily searchable.
Any reservations I have about Go aside, working with a real standard library again feels great. “Oh, I need a time function. Guess I’ll import ’time.’” Yes, standard libraries (heck, even the language itself) can change over time, but not all projects should have the same level of library churn. A simple command-line application that doesn’t interface with anyone but myself and a bunch of static files should almost never need changing, really just a monthly CI build with the latest version of Go to ensure that everything works fine should I suddenly want to add another feature. If I add third-party modules, I’m no longer operating on Go’s 6-8 month release cycle, but whenever the third-parties feel up to releasing.
Library stability is a feature - it means I’m spending my evening writing blog posts instead of trawling through a massive library refactor diff. It’s a little strange that in the software industry there’s a tendency to measure project vitality by how many commits have been done recently, instead of when the tests last ran successfully with up-to-date (not pinned) modules and language.