ctap (or: reasons I like Go and modern tooling)

So this weekend I scratched a long-standing itch and whipped up a little utility for colourising output. It's called ctap and is now available on Github.

I have a bunch of processes that spit out TAP output at various points as tests are run on outputs, and having the output coloured for fast scanning is a surprisingly significant UX improvement.

I've been a happy user of the javascript tap-colorize utility for quite a while, and it does the job nicely. Unfortunately, it's not packaged (afaict) on either CentOS or Ubuntu, which means you typically have to install from source via npm, which is fine on a laptop, but a PITA on a server.

And though I'm pretty comfortable building I've always found node packages to be more bother than they're worth.

Which brings us back to ctap this weekend. Given how simple the TAP protocol is, I figured building an MVP colouriser couldn't more than an hour or two - and so it turned out.

But what's really nice is all the modern tooling that provides you with impressive boosts as you go these days. On this project that included:

These are fun times to be a software engineer!

Perl to Go

I started using perl back in 1996, around version 5.003, while working at UBC in Vancover. We were working on a student management system at the time, written in C, interfacing to an Oracle database. We started experimenting with this Common Gateway Interface thing (CGI) that had recently appeared, and let you write interactive applications on the web (!). perl was the tool of choice for CGI, and we were able to talk to Oracle using a perl module that spoke Oracle Call Interface (OCI).

That project turned out to be pretty successful, and I've been developing in perl ever since. Perl has a reputation for being obscure and abstruse, but I find it a lovely language - powerful and expressive. Yes it's probably too easy to write bad/unreadable perl, but it's also straightforward to write elegant, readable perl. I routinely pick up code I wrote 5 years ago and have no problems reading it again.

That said, perl is showing its age in places, and over the last few years I've also been using other languages where different project requirements made that make sense. I've written significant code in C, Java, python, ruby, and javascript/nodejs, but for me none of them were sufficiently attractive to threaten perl as my language of choice.

About a year ago I started playing with Go at $dayjob, partly interested in the performance gains of a compiled language, and partly to try out the concurrency features I'd heard about. Learning a new language is always challenging, but Go's small footprint, consistency, and well-written libraries really made picking it up pretty straightforward.

And for me the killer feature is this: Go is the only language besides perl in which I regularly find myself writing a good chunk of code, getting it syntactically correct, and then testing it and finding that it Just Works, first time. The friction between thinking and coding seems low enough (at least the way my brain works) that I can formulate what I'm thinking with a pretty high chance of getting it right. I still get surprised when it happens, but it's great when it does!

Other things help too - it's crazy fast, especially coming from mostly interpreted languages recently; the concurrency stuff really is nice, and let's you think about concurrent flows pretty intuitively; and lots of the the language decisions like formatting, tooling, and composition just seem to sit pretty well with me.

So while I'm still very happy writing perl, especially for less performance-intensive applications, I'm now a happy little Go developer as well, and enjoying exploring some more advanced corners of a new language home.

Yay Go!

If you're interested in learning Go, the online docs are pretty great: start with the Tour of Go and How to write Go code, and then read Effective Go.

If you're after a book-length treatment, the standard text is The Go Programming Language by Donovan and Kernighan. It's excellent but pretty dense, more textbook than tutorial.

I've also read Go in Practice, which is more accessible and cookbook-style. I thought it was okay, and learnt a few things, but I wouldn't go out of your way for it.