Recently, I had the need to process a near infinite number of messages asynchronously. You can’t just throw all the messages into separate goroutines when there are that many of them and more incoming. One solution is to use some sort of worker pool to manage the number of concurrent goroutines that can run. Here’s how I went about creating a worker pool (I’ve called it a task pool) in Go.

I had the privilege again this year to fly out to Denver and attend GopherCon, the premier gathering of “gophers” (people who program in Go). It’s a lot of fun and I learn something every time. After spending the weekend hanging out around town with my wife, enjoying Hammond’s candy and exploring the Denver Museum of Nature and Science, I started the conference with a machine learning workshop. It turned out to not be quite what I expected.

A couple weeks ago, we had another hackathon at work. This time, I wanted to create something useful that could potentially be adapted by one of our teams. My initial thought was to convert some of our old C++ code to Go and remove a Windows dependency, but after talking with one of my coworkers, we decided to instead create a DNN service for executing a Caffe2 model in Go. We had a third volunteer join us and we set out to achieve our goal.

Recently, I had the pleasure of participating in an internal hackathon at work. They gave us two days to create whatever we wanted with whatever group of coworkers. There were no specific guidelines on what the project had to be or what technologies it needed to use, so I decided to go solo and recreate Conway’s Game of Life in Go. I’ve been fascinated with the Game of Life ever since I first heard of it several years back.