From JS To Go

One of the most popular and up-and-coming languages of recent is Go. To sum it up with just a few words it can be described as simple and performant. To improve the process of learning it can be helpful to relate what is to be learned to something already learnt. The new information can then be layered on top of previous knowledge and be easier to grasp. At least that is the hypothesis of this post. So what better “previous knowledge” is there than JavaScript considering its “anywhere and everywhere”-status of the development world.

A more thorough post on how to actually code in Go might appear in the future but for now I will just outline similarities for the JS-savvy developer to hopefully ease into Go.

The information is Mac/OSX centric where applicable.

Getting started

Install using Homebrew:

brew install go

Considering how simple it eventually turned out to be, it took me a while to browse through old information until I found more recent describing how to enable handling modules the modern way. To make a long story short add this to your .zshrc (or whatever is your corresponding file depending on preference of shell):

export GO111MODULE="on"

Basic tooling & commands

Help

The help functionality is convenient and the concept resembles man pages providing help by the command line. To get help on a package:

go doc PACKAGE

Help can also be more granular, e.g. getting help on the function Println of package fmt:

go doc fmt.Println

Packages & modules

Code is structured into packages and modules where a module can be viewed upon as a project file which declares packages used in the project.

A module is initialized by the following command which will create the mod.go file:

go mod init MODULE

To install public packages into your project:

go get PACKAGE

A good practise is to tidy your module after installations. Tidying simply means that your module is checked for unused dependencies which will be removed. Used packages will be grouped into direct and indirect sections in your mod.go. Indirect packages are sub-dependencies to the packages you have explicitly installed.

go mod tidy

To list all packages of your module:

go list -m all

To list available versions of a specific package:

go list -m --versions PACKAGE

Last but not least, build a package:

go build PACKAGE

JavaScript similarities in Go

Basic similarities

Anonymous function invocation

Before module systems like AMD, CommonJS and ESM were a thing in the JS world it was common to use “iffys” or Immediately Invoked Function Expressions (IIFE). There are several ways to turn a function declaration into a function expression (have a look at a Webpack dev bundle and their use of + for a not so common but terse one).

I used to embed the function declaration in parenthesis and then simply slapping on the invocation bit, i.e. the arguments within a final set of parenthesis.

(function (message) {
	console.log('message');
})('Greetings from JS!');

Go uses a similar syntax for anonymous function invocations.

	(func(message string) {
		fmt.Println(message)
	})("Howdy from Go!")

Wrapping up

Consider this a simple introduction to Go for anyone coming from a JS background. I lack serious experience as of now but my very early opinion on the language is that it is simple and easy to get going with and whatever you have heard about performance seems to be true.

The simplicity of the package and modules system is convenient and reminds me a bit about JS. I also like the type inference. There is something liberating with Go which, beyond the aforementioned, I cannot pinpoint at this time.

That said, on the negative side I find it too imperative. While supporting higher-order functions (functions are 1st class) there is not much else about Go that enables a FP mindset. Hopefully I will revise that opinion in the future.