For my latest hackathon at work, I decided to work on optimizing some concurrent code in one of our microservices. We had clean concurrency at one point, but then we added a branching path for a new feature and then we added another feature and then another. It quickly snowballed and got way out of hand. I restructured the code a bit and took advantage of the C# Task pattern. Azure helpfully has a Go package for C#-like async tasks and I was able to use this to simplify handling results from goroutines. Anyway, that’s not what this blog post is about. While I was trying to figure out a good way to reorganize the code, I thought it might be useful to create some sort of workflow manager that can call functions sequentially or in parallel, make decisions on which functions to call, catch errors, etc. My first inclination was to create something using a fluent interface and the builder pattern, but after reevaluating and rewriting my approach two or three times, I settled on a version consisting of chained higher-order functions. After finishing what I set out to accomplish, it turns out it wasn’t all that useful and I didn’t end up using it, but it was a fun exercise nonetheless.

For a recent hackathon at work, I decided to create an API-based multiplayer game, something along the lines of SpaceTraders or Rubbled. The idea is the entire game is built in a service with a REST API for issuing commands. There is no UI or client provided; players must create their own user interface or automate the commands somehow. I’ve worked on games before, but I haven’t ever created an online multiplayer game, so I thought this would be a fun experiment. My desire was to create the game in Go so I could take advantage of the concurrency primitives it provides and spend some time getting familiar with the new slog package for logging. There wasn’t much time available to work on this project, due to other pressing work issues, but I was still able to get a simple service running with a few basic commands.

GopherCon was back in San Diego this year! As such, I was able to attend yet again. The conference was well worth attending and I had a great time. There were some great talks, a rather unusual workshop, and even some interesting sponsors/exhibitors. Here are some of my highlights!

Workshop: Intro to Rust #

Why go to a Rust workshop at a Go programming conference? Good question. I believe it is valuable to explore other programming languages to gain experience with different approaches to software development. Rust is often compared to Go, albeit unfairly so. Go is heavily focused on microservices and ease of use for developers. Rust is more focused on memory safety, replacing C++, and blazing fast speeds. A developer can learn Go and deploy code to production in a week, but Rust has an infamously high learning curve. Along with this high learning curve comes a wealth of different features and the incredible claim of no memory leaks.

Ever need to just completely clear out an S3 bucket or a DynamoDB table using the AWS SDK? Think it will be one SDK call and then you’re done? Not so! The S3 console has an Empty button for each bucket and the AWS CLI has a aws s3 rm --recursive command. But the console doesn’t lend itself to automation and the CLI command doesn’t work for buckets with object versioning turned on. DynamoDB has similar limitations. One of the recommended methods for DynamoDB is to describe the table, delete the table, and then recreate the table with the exact same properties. This might not always be an option though. So in order to use the AWS SDK for either S3 or DynamoDB, you need to write a bit more code to query all the items/objects and then delete them all in chunks. Since I had to do this recently, hopefully these code snippets will save someone a bit of time.

Every decade or so, I become fascinated with sorting algorithms and spend some time implementing various approaches in my language of choice. The first time around, it was C++. Last time I took a stab at it, it was C#. This time around, I wanted to implement some popular sorting algorithms in Go. I think I enjoy it so much because sorting is easy to verify and there are so many varied approaches. A lot of people have spent a lot of time and energy coming up with creative methods for organizing array elements. I also wanted to use this as a test bed for some relatively new language features in Go, namely generics and fuzzing. Finally, I wanted to code with some assistance from ChatGPT, to see what it could do for me as a programming tool.

Go Modules is the official dependency management solution for the Go programming language. Recently, I finally converted over my personal projects. I had been putting it off for some time, since I was waiting for the Go team to finalize everything and work out all the kinks. Go 1.11 was when Modules was first released as a beta. Go 1.12 still had Modules in beta mode and Go 1.13 was when Modules came out of beta. After Go 1.14 came out, I figured it was probably time to transition over from dep (which is deprecated now). It was a mostly smooth experience, but I did run into some snags. For example, upgrading a package that has already had its major version incremented to 2 or greater requires a bit more work. In an effort to share my findings, here are some common commands I found useful.

When I attended AWS re:Invent at the end of 2019, I attended a workshop for using machine learning via Amazon SageMaker to teach an AI how to play blackjack. Seeing as re:Invent was held in Vegas, I decided to take the spirit of Vegas home with me and create my own text-based blackjack game in Go. I added a simple interface so it would be easy to create different AI opponents. I had another hackathon coming up at work and I thought it would be cool to try and train a model to play a better game of blackjack using SageMaker. This would be different from the workshop I attended in that they were mostly focused on recognizing a card’s rank and suit, whereas I wanted to look at dealer/player hand combinations and retrieve predictions on the outcome of various actions.

This is waaaay overdue, but we had another hackathon at work back in September of last year and even though I’m waaaay behind on blog posts, I wanted to make sure I did a short writeup on my project. During GopherCon, I received a small Arduino Nano 33 IoT. Not exactly a powerhouse, but I wanted to do something with it. I bought a breadboard, sensors, wires, and other various components. I still didn’t know exactly what to create, just that I wanted the programming component to use TinyGo.

I recently spent some time figuring out how to gracefully shut down a Go service. The goal was to allow in-flight transactions to complete successfully before shutting down, but return Unavailable for any new requests. I found the solution to be fairly straightforward for Linux, but a little bit more tricky for Windows, specifically when running in a Windows Docker container.

General solution for handling termination signals (Linux/Darwin) #

For most use cases, the os/signal package works for capturing termination signals:

Another year and another GopherCon, this time in sunny San Diego! As usual, there were a lot of high quality talks across a breadth of subjects. I highly recommend browsing through the GopherCon videos on YouTube, but I’ll highlight what I thought were the interesting bits below.

The last year or so has seen a LOT of discussion around dependency management for Go, particularly around dep and Go Modules (formerly vgo). Previously, dep was the “official experiment” for dependency management for Go, but was superceded by a proof of concept called vgo that became what we now know as Go Modules. Go Modules is being actively developed in the Go toolchain and is the future of dependency management for Go. While dep is a fine choice, it’s clear that the Go team will be pushing Go Modules hard. This was made clear in Russ Cox’s introductory talk regarding the future of Go 2.0. I’ve always been more in the dep camp, but a lot of my concerns were alleviated by what I heard from Russ. Also, there was a fantastic talk later on by Aaron Schlesinger about Athens, a free, open source mirror for Go Modules. It seems to me that Go Modules will be in a good place to take over dependency management for Go in the near future.

When the theme for our latest company hackathon was revealed to be “Need for Speed”, I went straight to Best Buy after work and picked up a DJI Tello drone. I had been wanting one ever since I went to GopherCon and saw the presentation by Ron Evans where he used Gobot and GoCV to make a Tello drone follow his friend’s face around. Now that I had a drone, I needed to figure out what to do with it.

Something that Go does very well is multi-platform support. You can build a binary for just about any system without much hassle. On a single build machine, you can build binaries for Windows, macOS, and many flavors of Linux. All that is required is to change the GOOS and GOARCH env variables to the desired OS and architecture. I made a Makefile to take advantage of this.

First I started with a few variables. EXECUTABLE is the name of the program to build. WINDOWS, LINUX, and DARWIN are the actual names of the binaries to be created, based off of EXECUTABLE. VERSION is a version string derived from the latest git tag and commit hash, something like v1.1.1-8-g99740b5.