I am going to go through my thoughts and opinions on Golang, Google’s fancypants compiled language. I will be writing this as I go through the tutorial for Super-Fresh Hot-Takes™, so this will be extremely opinionated (and also probably wrong somewhere).

First: Go’s Tour (and Tutorial)

To start Go’s tutorial, you simply run go tool tour wherever you can find Go (wherever you installed it, C:\Go\ on Windows, for example) and you get this browser window with a very interactive tutorial on the basics of the whole thing.

This is amazing. I can’t think of a single other programming language where the tutorial for using it is baked right into the tooling/SDK of the language from the get go.

That all said, I definitely have one misgiving of the tutorial series: they go through a lot of effort to use single-letter variable names, function names, type names, everywhere. This is fairly frustrating to try and parse out how things are support to work in my head.

Go’s Syntax and Enforcement

This is definitely a different language from most I interact with on a daily basis. A lot of stuff I’d expect it needs to look like it doesn’t. It reminds me of when I started learning Python and had to work with things not needing end tags and spacing being all the difference in the world.

The authors of Go definitely make an effort to make sure conformity is a thing with the language. Not many languages build in a tool that formats the code in a standard way in its standard toolset. Mind you, PHP has PSR series, but it’s optional and 3rd party. Python has pep8 but there’s no built in tool that reformats your code to it. Go, however, has go fmrt and at least with Gogland by IntelliJ you can have it auto run on save.

Making sure all your Go code looks similar and is formatted similar to me is a noble goal. Although I do have a serious issue with the amount of usage of single letter variables in their tour series, I like this as an approach that I wish other languages would adopt.

Unfamiliarity Abound

Looking at the syntax below, this is pretty crazy:

// From the "A Tour of Go" built-in series

import "math/cmplx"

var (
	ToBe   bool       = false
	MaxInt uint64     = 1<<64 - 1
	z      complex128 = cmplx.Sqrt(-5 + 12i)
)

Rather than declare each on its own line with its own var, or doing something similar to JavaScript where you can comma-chain declarations, Go lets you just wrap all your variable stuff in parenthesis and you’re good to… well, good to go.

An interesting part of this to is that Go wants the variable declaration sequence to be: var $name $type [= $value]. In a lot of the languages I’ve worked with (C# for example) the sequence would be: $type $name [=$value], or even shorter var $name [= $value] where type is inferred.

Anyway, breaking down the code above into a nicely formatted table, we get a little nicer understanding:

Small side-note: it blows my mind that complex numbers are supported out of the box. That’s just really cool and crazy in all the right ways. I don’t know what I will ever do with it, but it gives me an excuse to work with them more.

Unfamiliarity 2: Lack-of-OOP Boo-ga-loo

Go doesn’t do Object Oriented Programming (OOP). I found this an interesting design choice for a new language - especially since this will likely be used in large projects. I’d be interested in seeing how people work into organizing their codebase with this in mind.

Code Example

Without further ado, I wanted to jump in a code example that made me like a feature of Go that exists in OOP (and maybe other ways too): Interfaces! Interfaces are a lot like a contract you want code to conform to. In Go, that contract is not explicit, but instead implicit and checks on assignment.

Let’s look through a code example:

// From the "A Tour of Go" built-in series

// Declaring our package
package main

// Importing our dependencies. Interestingly, errors out if we have an unused one.
import (
  "fmt"
  "math"
)

// Our demo example interface (I am using this one as an example, I am aware of Stringer)
type Printable interface {
  // Anything that implements this interface, must have PrintOut attached.
  PrintOut()
}

// Let's look at our favorite band.
type FavoriteBand struct {
  Name string
}

// Implement PrintOut by FavoriteBand
func (band FavoriteBand) PrintOut() {
  fmt.Println(band.Name)
}

// Our favorite number (If you guessed it's going to be Pi, you will be wrong)
type FavoriteNumber float64

// Implementing our favorite number. We can just print out the number
func (number FavoriteNumber) PrintOut() {
  fmt.Println(number)
}

// A helper for us (directly borrowed from doc)
func describe (item Printable) {
  fmt.Printf("(%v, %T)\n", item, item)
}

func main () {
  // again, var <name> <type> = <value>
  // Our type is Printable, meaning anything assigned to this must implement that interface.
  var first Printable

  // First things first, our favorite band.
  first = FavoriteBand{"65daysofstatic"}
  first.PrintOut()
  describe(first)

  // Our favorite number
  first = FavoriteNumber(math.E)
  first.PrintOut()
  describe(first)
}

And for the output of the above:

65daysofstatic
({65daysofstatic}, main.FavoriteBand)
2.718281828459045
(2.718281828459045, main.FavoriteNumber)

In the example above, there’s no explicit definition that FavoriteBand, a struct, implements (or, conforms) to the Printable interface. Instead, when we declare first we declare it as type Printable, so anything assigned to it must implement that interface. Once we assign FavoriteBand to the variable first, are when things are verified.

This is pretty cool from a flexibility standpoint, though I can confidently state I have no idea how far I can go with this. It’d require a lot more work with the code to get the concept hammered into my head (I’m the type of guy who needs to do things 50 times to understand them).

Finishing up the Tutorial Series

I was sort of doing this as a live blog, but then I got caught up into the Go Tour series. I found the exercises for the series pretty good, though I feel the series on Channels to be a little short. I also had the Equivalent Binary Trees exercise kick my butt for awhile.

All and all, Go seems to be a pretty cool language, and I hope to write some stuff in it for the future. My current personal project is to better learn Go, and also do some more work with the modern era of JS frontend tech.

Future

I think I’ll definitely write more about my work with Go and what I do with it. I would like to expand the comfort I have with languages, especially ones that are as fast and neat as this one, to expand my toolset going forward.