I am Loving Golang tooling
I recently interviewed for a role as a Golang Senior Engineer. I wasn't very interested in the culture. There seemed to be a distinct lack of things I was excited about; even after the recruiter was kind enough to get back to me with more information. What it allowed me to do was make the excuse I needed to start compiling, testing, debugging things in go seriously for the first time in a little while.
As a generalist in computing, I often find myself torn between tasks. Things like writing a blog article, improving work documentation, finish passion-projects, be a good husband, be a good family member, brother, son …
Another thing that can make it hard to "come home" or at least visit, is developer friction.
There are many kinds of developer friction a term used to make tactile the feeling things could be better.
The one type, or way I'm focusing on it here is technical or tooling friction. How long do I need to spend, before I'm set up?
When I'm being a grump, I like to blame tooling for the rise of languages or pattens I don't enjoy existing. It's short-term enjoyable, but long term facile both to hate on languages and technologies, and to expect mass adoption without ubiquitous tooling.
What golang gets right
10,000 foot view
A Bit like Python, which I also love; golang has some strong opinions.
- Concurrency should not be an after-thought.
- Formatting consistency IS important.
- The standard library should be about more than passing a CS exam.
- Documentation, coverage, testing & debugging should be front and center!
- Types are important, but you should be able to work around the type system.
- Objects are a way of talking about relationships, we can borrow from.
- C is here. We'll need to play with it.
- You can (most of the time) deploy a single executable.
I have an authoritarian streak I cannot shake, so I rather enjoy being told off by a language for bad habits, and for it setting ground-rules. I should probably see a therapist about this, but typing with the ability to turn off when I'm desperate or stupid enough, is a wonder. I love strict typing, like I love expressive API's, but sometimes you need to get into
the mud and the blood and the beer to get things done.
I'm probably getting a bit boring so I'll wrap up this, but a standard library offering networking, common standards written in the tooling you use has amazing benefits for testing and understanding what the **** you're doing when stuck. Offering debugging and integration with support for expressing yourself similarly to other languages through interfaces etc, is also brilliant.
Me and golang
- Serverless functions using OpenFaaS
- API projects for high-throughput around payments and invoicing
- Command line applications without requiring extra runtimes or software
- File storage API for uploads
- Various test & exploratory projects
- Cross-compiling for multi-arch targets
- Understanding code such as CloudFoundry & Docker
- Understanding and (hopefully helping to re-organise) SQL in cockroach DB
- Integrating with Linux tooling for GUI's using Go & C-bindings
I think it's safe to say that I'm still beginning my journey into all they can offer. I Feel a few new things came up
- A language-directed plugin build target, which looks promising for faster data-store-flexible systems.
- Cross-architecture builds, which I've paired with GitHub actions for an SMTP testing / control MailHog.
- Spec testing, specifically testing patterns.
I really enjoyed a jaunt with Golang and will endeavour to finish some of my newer projects using it. I am transitioning towards low-code, no-code and less-code solutions; because I'd like to tackle what I feel are some foundational issues for practical computing personally and for business; but I also love what 20 years has produced so-far, and cannot wait to be a part of the next 20.