The computer language war has been on since the creation of the pyramids, so I thought I would like to add my non-contribution to this discussion.

On my day-to-day basis, I do not use go. I use several languages for work such as Java, Scala, and rarely python, and maybe Javascript. I use go, or the so called golang, to write utilties, such as seeding a database, moving files from a location to another, starting jobs or calling APIs for testing and debugging, building reports from many files, and other use cases. What I would like to address here are reasons for why I use Go and address the what is not a reason for me using go for such task.

Go is simple

It is wide-spread reason for chosing Go.

However, it is unclear what one mean by “Go is simple”. If simplicity is corrolated to the number of keyword a language it has, then indeed Go is very simple. Go, as of 2020, has less keywords than C. If simplicity is corrolated to the number of constructs a language has, then maybe, though I have not calculated, Go is simple. If simplicity, however, is corrolated to how easy it is for one to read code, then certainly Go is as simple is most other languages.

You see, I fear that in conferences and in blogs, many advocate “Go is simple” to mean the Go is simple in the first sense, or possibly the second: it has few keywords, few constructs, and that the listener or the reader interprets “Go is simple” in the third sense: that reading the code is very simple. I certainly might be wrong.

It certainly matters how may keywords a language has, but only to some extent. It certainly matter how many constructs a language has, but also to an extent. What matters more in a collaberative, medium to large work is simplicity in the third sense, that a language is easy to read and reason able. The fact is, reading a language becomes a second nature when a person is familiar enough with a language. Consider this snippet in for node js taken from aws docs:

// Load the AWS SDK for Node.js
var AWS = require('aws-sdk');
// Set region
AWS.config.update({region: 'REGION'});

// Create promise and SNS service object
var deleteTopicPromise = new AWS.SNS({apiVersion: '2010-03-31'}).deleteTopic({TopicArn: 'TOPIC_ARN'}).promise();

// Handle promise's fulfilled/rejected states
deleteTopicPromise.then(
  function(data) {
    console.log("Topic Deleted");
  }).catch(
    function(err) {
    console.error(err, err.stack);
  });

For those who are not familiar with node js can still read this code, but it will require re-reading once or twice. For those familiar with node, this is a straightforward code. There are many parenthesis and a promise, and promises do not exist in every language, yet a node js developer read this code quickly because they are familiar with the language and their constructs, and the idoms used in it.

Consider this snippet in go. This is a snippet from an example in the go scanner package:

var s scanner.Scanner
// ...
for tok := s.Scan(); tok != scanner.EOF; tok = s.Scan() {
	fmt.Printf("%s: %s\n", s.Position, s.TokenText())
}

This is also simple to read, I think. Yet, none-go developers will re-read the code to understand the purpose of EOF. But for a typical go developer, this is simple.

My proposal here is that simplicty, when simplicity means the easiness of reading code, is influenced mostly by the experience of the developer in the language. Languages have quirks, weird, or uncommon features that new comers will take an overhead in reading, but experienced will read much quickers without problems. I have developed in Java for a while and reading Java code is easy, even though it is filled with classes, inheretence, interfaces, overrides, and optionals. But I might struggle a little with interface embedding in go.

But there is a fourth sense of simplicity, and that is that go is simple to learn. This is probably true if you do not want to use some of the advanced features. You can build decent utilities from just going though the 20 minutes in “A tour of go” website.

Go is fast

When Go is said to be fast, it is compared to other popular programming languages that are slower than Go, such as Python and Ruby. It could be the case that Go is generally faster that the two, but it is hardly a reason to learn Go, let alone use Go. Languages that Rust are faster than Go, and therefore should be used when speed is a requirement. Speed, however, is generally not a requirement. Wordpress is written in PHP and still support many websites that are visited heavily. What is important about scale is the architecture of the solution, not the language of implementation.

Go builds a single binary

This is a very important advantage for a utility language: Go generates a single binary for the utility. This simplifies using these utilities by adding the binary into the PATH directory. Go takes this slightly further: you do not need to create a package and publish it somewhere for you to use it on a different machine or give it to a different user. Instead, you can simply run go install GIT_URL. This makes the process tremendously easy.

Many other languages have a central package repository where package authors can upload their repository. This process has advantages such as maintaining security (suspecious packages are removed) and authenticity (the package is directly from the author). However, for a simple utility, this is an overhead. Plus, sometimes you do not want to share the utility with the public because it is not meant to.

In general, and in the software development process of an application going from non-prod to prod environment, this makes little difference. The runtime is always installed on the destination machine. And if the software should be installed on user machines, the runtime is always packaged together with the software in one way or another. Rarely is it a concern that you cannot install runtime on machine.

The real reason for using Go

Because I learned it. Really. There is no complicated or sophisticated reason for it. I reviewed the “tour in go” few a hour, picked it up quick, and that is why I still use it. If I picked up python, I would have been using it instead and not learned Go.

The fact that it has decent number of packages, reasonable concurrancy constructs, and works with major cloud providers cause me to think I do not have a reason to switch soon.