I’ve worked with Go(lang) professionally for over eight years. Now, while some might say I don’t have enough experience to be able to get an entry-level job (looking at you recruiters), others might say that I’m qualified enough to understand Go’s benefits and pitfalls.

Today, we look at how Go’s quick and easy cross-compilation can be a deciding factor when answering “Why Use Go?”.

The first use case that led me to migrate a project to Go was a requirement to work across multiple platforms to extract, transform and load data.

Working in the education space, we had Schools with on-site servers running their Student Information Systems (SIS). New Zealand has never had a centralised database or a uniform format for sharing student data between SIS systems, making it one of our consistent pain points.

One of these systems we worked with had a cron function that could export different data periodically to CSVs, so we needed a client app that could read these CSVs, massage the data and push it up to one of our secure sync APIs.

At the start of this project, I mainly worked with Windows server machines, where Python seemed like a good idea. I knew it well due to using it throughout University and in my first coding job. But we ended up with hidden issues.

Certain SIS vendors happened to use Python under the hood to run cron jobs or perform some beta scripting “magic”. You also had a chance that certain IT vendors would have installed Python on these servers to provide a consistent scripting language. But this was during the Python 2->3 migration hell where servers could also be running Windows Server 2003, 2008 or 2012 in 2016 - before PowerShell was a thing.

So here we were with numerous (potential) issues:

  • Windows Servers could be a mishmash of 32/64-bit versions
  • We had to cater for MacOS due to a couple of mac only schools
  • Local Python installations could be any variety of garden snake
  • Virtual environments were available with Python 2.7

BUT

  • Our clients would generally be the ones installing our application, so upgrading and installations could be a cause for failure, and I didn’t want to go down the path of hand-rolling an installer for something with very minimal updates

In this moment of despair, I remembered the fabled words of an enthusiastic Portuguese manager I worked with as a Cloud Engineer. He promised blue skies of light resource usage, nearly instant cross-compilation with incredible performance for numerous operating systems and architectures encased within a single binary.

Here, deep within the overwhelming darkness of night, I wrote my first fmt.Println("hello world").

Shit.

It didn’t compile.

Oh, I missed a brace.

One from __future__ import braces later:

go run main.go

Hello World

I smiled, and a slight welling occurred in my eyes.

Much like the devoid light emanating from my dark theme, the light ever so slightly began to shine through my despair. A new day was dawning.

We shipped that client as a single cross-compiled 3.5MB binary to Mac and Windows hosts running across x86/x64 platforms, running perfectly from Day 1. The big win always came from IT Support being able to copy and paste a single file when performing updates. Someone would always astoundingly enquire, “Is that all?”.

Having worked in IT support, I had the opportunity to learn the pain of deployment across many applications, drivers and packages. From this understanding, it’s always been an aim of mine to make the apps I deliver as simple as possible for anyone to pick up and work with.

From that moment, it’s been Go all the way for me, and the language has continuously improved throughout the years since. More recently, we have continued to build on internal tooling with Go for initial project configuration, code generation and codifying monotonous one-off maintenance tasks. Go’s Cross-compilation story has been a big boon for our developers working across Windows, Mac, Linux and Docker Alpine images.

Due to this, Go’s near-instant ease of cross-compilation to a single binary across various platforms and architectures has made it a well-used and oft-picked tool from the toolbox and one of the reasons I would look to choose Go in the future.

Thanks for reading!

“Why Use Go?” is the first post in a series of when and why you may choose Go as a tool and how it has helped the company I work for (Hero) grow from 50 to over 600 Schools with ~180,000 monthly active users. Next, I’ll look at Go’s performance, Team productivity and how its ecosystem has evolved to be world-class.

Make sure to like and subscribe 😉