Member-only story
How To Approach Concurrency in Go
Is concurrency always the best choice? Let’s find out
This article aims to demonstrate when using concurrency can be more beneficial depending on your program’s workload type.
Therefore, I will not cover popular concurrency terms such as goroutines, wait groups, channels, and data races, among many others. I have in mind creating a series of articles explaining useful examples of the most used concurrency building blocks and quirks in detail.
How To Approach a Problem?
One of the common mistakes in my early days with concurrency was trying to implement problem solutions using concurrency from the very beginning. Not only did this make finding the optimal solution more difficult, but there was a risk that using concurrency was inappropriate for that problem.
Based on my experience, I suggest you start by getting a working sequential solution and then iterate, if necessary, to check whether it makes sense to implement a concurrent solution.
Try to solve the problem with a sequential solution before thinking about concurrency.
Concurrency and Parallelism
I will not explain in detail what concurrency and parallelism are since there are many well-explained articles on the internet. Still, I will leave a couple of definitions from one of the creators of Go:
“Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.” — Rob Pike
“Concurrency is about structure and parallelism is about execution. In other words, concurrency is a way to structure a thing so that you can (maybe) use parallelism to do a better job.” — Rob Pike
Workloads
One useful way to know whether concurrency can be a good fit is to understand your program’s workload. There are mainly two types of workloads to be considered when analyzing concurrency:
CPU-bound workloads
They describe a situation when the execution of the program is highly CPU-dependent; it is directly related to the speed of the central processor unit.
