Use Go, Embrace Channels and Be Responsible – InApps Technology 2022

We have been seeing more examples of how the Go programming language’s concurrency and its simplicity are advantageous over other languages. Go’s concurrency is supported by its use of “goroutines” and channels, and in this talk from Gophercon India, William Kennedy — managing partner at Miami-based web, mobile and systems development company Ardan Studios and author of GoingGo.net and Go In Action — talks about how Go’s channels give it a consistency and predictability.

Go In Action: Use Channels and Be Responsible

Also available on Apple Podcasts, Google Podcasts, Overcast, PlayerFM, Pocket Casts, Spotify, Stitcher, TuneIn

Kennedy begins by recounting how he was previously developing products using Microsoft’s C#, but reached a critical point when he realized he was making Microsoft more money than himself. So after this “depressing” experience, his company moved over to Linux and Go.

Channels were one of the first things Kennedy noticed in Go. “Everyone comes to Go for channels, and then they discover inheritance, type embedding and constants,” says Kennedy. He found the synchronous queues “cool” in Go, and began writing Go code with synchronized activity in mind. But he quickly realized his code seemed more complicated than it needed to be, and that it also wasn’t working. So, he eventually reached out to the Go community for advice.

Kennedy then learns that unbuffered channels are the key to guaranteeing consistent synchronicity, ensuring data from one goroutine has been received by another goroutine. This guarantee is what Kennedy is enthusiastic about.

In contrast, Kennedy recalls when object-oriented programming became a “big thing,” due to its promise it could model the real world. But its limitations eventually became apparent, says Kennedy: “You can model the real world, define the data and the methods, but when the code ran, did it really run like things in the real world? No. Because all the synchronization we had to do, all the … threads we had to make for it to interact properly — it couldn’t be done.”

Kennedy contends that Go’s unbuffered channels, and the underlying idea of responsibility and guarantee, allowed him to write code that could finally mimic the real world for the first time, “without all of the extra stuff around it.”

To explain how Go’s unbuffered channels operate, Kennedy walks the audience through an analogy, written as a piece of code depicting a relay race. The “runners” are ready on the “track” of the main goroutine, waiting for the baton to be passed to them (the baton here represents data). The runners cannot run forward without having the baton passed to them — a programming metaphor for the “responsibility and guarantee” that Go’s unbuffered channels offer. The “send” of the goroutine cannot happen without receiving — “the receive is the guarantee,” points out Kennedy.

Kennedy says when he starts writing concurrent Go code, he always starts working with unbuffered channels. If it’s written as a buffered channel, he notes first, there must be a good reason to be choosing a number for the buffer and treating the channel “as a queue that could never get full” — which can potentially lead to crashes, when the unforeseen happens. Second, Kennedy asserts that it’s better to write the routine as an unbuffered channel first, and to instead “deal with the [resulting] pushback,” because “every system has a breaking point … and it’s [our] job as programmers to know where that is … so you can monitor it, know how and where the system needs to grow, help improve it over time.” In addition, Kennedy notes another issue with buffered channels is the possible loss of data when the buffer becomes full.

In the end, Kennedy has this to say about Go’s implementation of channels: “When I’m looking at code, [I say] forget about syntax, forget about the mechanics [of] how the channels work. I want you to look at it in terms of what you are trying to accomplish here. What are you trying to do? Then you can look up how you can do that. … So, that whole idea of what is a channel providing? It’s providing a way of accountability on responsibility, and the guarantee that this piece of data has moved from one goroutine to the next.”

Read more about channels over at GoingGo.net.