Adventures in Go
Creating my first Go application, a command line tool
As promised I tried another language, this time it was Go. After fiddling with some “Hello world”s and tutorials, I decided to try writing a cross platform command line app.
Go is a very small and simple language, and I was able to get what I wanted from the app very quickly. After all, all it does is pull git repositories.
After getting the functionality down, I needed to build for each platform. The first thing I stumbled across when trying to achieve this goal was goreleaser .
As it’s description says:
GoReleaser builds Go binaries for several platforms, creates a GitHub release and then pushes a Homebrew formula to a tap repository. All that wrapped in your favorite CI.
And, to my surprise, it did exactly what it said on the box using exactly the steps described in the README. I was actually suspicious when it worked and built the binaries using Travis-CI. I am used to fighting with Travis config files to get things working, but here all I had was this one liner in the Travis file, a small .yml configuration (with good defaults) and of course I had to generate a GitHub API key and configure it in Travis, but that was it, done! I was building and executable for all three major operating systems and those were automatically pushed to GitHub releases every time I tagged.
This amount of power for such a minimal amount of effort cannot be understated and the more I looked in the Go ecosystem, the more I saw tools that were just as easy to use. I like simple, it gets stuff done in a short amount of time, and that’s really good for side projects and little tools, and maybe even bigger things too. The language itself is part of that simplicity, it has a rich standard library that contains a lot of what I need and there are also tons of useful third party libraries.
I know this sounds like some sort of weird (and very late) language review, but, well it sort of is. I’m impressed, very impressed. I don’t think I have ever had this great of an experience with a modern compiled language.
However, simplicity came to a halt when coming up with an installation solution. To be honest, outside of tools written in node, I have never written a command line tool where I cared about the deployment process. Linux and macOS were and easy solve, just copy the binary to the right directory and you will have access to it in the terminal, I made this even easier with a one line shell file:
#!/bin/bash
cp new /usr/local/bin/
But of course this is not so easy in Microsoft Windows. I wasn’t really comfortable with copying the thing to System32 so after some Googling, I came to the conclusion, as many StackOverflow threads on the topic had suggested, that the path to the file has to added to your Environment Variables. Not only did this suck because I now had to decide on a directory in which to install only one binary file, but for some reason this method only gave me access to the command in an Administrator mode. I needed something with way less friction, and it needed to work, that was also a requirement. This is where scoop came in.
I first discovered scoop when reading the gradle install docs, and it’s path being in the environment variables reminded me of it’s existence. So off I went to the documentation and… wow! Although it’s not a Go tool like the ones I mentioned earlier, it is another example of beautiful, easy to use simplicity.
Scoop allows you to create your own “Buckets” which put simply, are your own package lists that contain the instructions to install any executable. Doing so is a matter of setting up a git repo with a JSON file in it. After adding the bucket. All I needed to do was use scoop to install my app, and it worked! Full access in even non admin command line.
So at the end of all that, building my first useful application in Go was a really good experience. And although the language is simple and to my horror doesn’t seem to natively contain my favorite map,reduce and filter functions, I really enjoy using it because of how quickly it allows you to achieve something with minimal friction. At the end of the day, that’s kind of all you want out of a language. Fancy features be damned.
Of course every cloud becomes a storm, and there is one major downside to this language, one that I think frankly holds it back from being taken too seriously and possibly hinders it’s adoption; The horrendous logo.
The caricature of a barely sentient flattened jellybean is not only an assault on the senses but an insult to the intelligence of anyone who isn’t immune to embarrassment. I get that in the tech world we like to be playful, but I honestly think that this branding decision could hurt adoption. People are affected by branding even when they think they are not.
In the end, I like the language, and I am eager to try using it beyond simple utilities. I also would not be surprised if adoption grew to be even more popular. I might even go far enough to say that it might be a good language to learn for beginners, although they may feel you have insulted their intelligence by sending them that link, thanks to that gruesome illustration of a “Gopher”.
