This afternoon I authored a very simple web application in Go. I’ve developed DLLs and command-line tools with Go in the past, but this was my first real Go web app outside of demos and tutorials.
I wanted to build an application to track my daughters first words. The required persistence is simple word + date pairs. You don’t want to repeatedly enter words, so I included a prefix-search JSON web service which dynamically shows the user any previously entered words beginning with the search term: auto-dissuade if you will. This feature also acts as a mechanism to review what words were previously stored.
With Go, like Java or Node.js, its easy to find and use an embedded web server technology. This sets it apart from .NET, where only recently has a reasonable embedded web server option existed. However, what genuinely makes Go stand apart is the application packaging aspect. Idiomatic Go strongly favors static compilation into a single .EXE file. Consequently, most libraries in Go are distributed under business-friendly BSD / MIT style licenses.
What struck me, however, was how thoroughly the option of having a single .EXE appeals to me. Although Go has a built in templates library for loading HTML from external files, I opted instead to embed my HTML within the .EXE. I further sought a fast, embedded data store – settling on LevelDB.
I feel that the critical distinction here, is how easily deployed my solution is: one .EXE. A similar application using Microsoft technologies would require .NET, IIS, SQL Server, a dozen DLLs, and likely a WIX installer to bundle these items. A naive Linux implementation might require Python, Apache, Redis, 3rd party libraries, and hopefully a Docker package to bundle it all up. Its easy to trust that 3rd party database will be running when we need it to be, but there is a significant overhead in guaranteeing such things.
With Go, its surprisingly easy to consider a web server or standalone database as unwanted complexity, another point of failure, or simply another thing to learn. Pundits may focus on micro-services and such, but its easy to see where such solutions simply shift complexity from the hands of developers to the hands of the dev-ops team.