Learning Golang: Introduction to Concurrency Patterns, goroutines and channels

Welcome! Let's learn about Go/Golang Concurrency Patterns, but first let's learn about concurrency in Go/Golang, including goroutines, channels and the different keywords needed: like close, range and select.

* What is a goroutine?
It is lightweight thread managed by the Go/Golang runtime, independently executed function that has its own call stack.

* What is a channel?
Is a mechanism through which we can send and receive values, it uses the arrow operator which indicates data flow.

By default sender and receiver will block if the other side is not ready

* What is a buffered channel?
It's a type of buffer that has a length.

Sending to a buffered channel will block if it is full and receiving from a buffered channel will only block when it's empty.

* What else can we do with channels?

There are 3 new keywords applicable to channels: "close", "select" and "range":

* "close" allows closing the channel, this means we can't receive or send values to it.
* "selects" allows to receive messages from multiple channels via "cases", it's like a "switch", it also supports a "default" value.
* "range" is similar to the keyword used when looping through slices/arrays; but in this cases it will continuously receive values from the channel until it gets closed.

Recall this is the "Introduction to Concurrency Patterns in Go/Golang", in future episodes I will describe concrete patterns to use when building concurrent programs.

---

RELEVANT LINKS

00:00 Intro
00:16 What is Concurrency?
00:36 What is Parallelism?
00:46 Analogy: Concurrency
01:53 Analogy: Parallelism
02:20 What is a goroutine in Golang?
02:49 Example: goroutine in Golang
04:03 What is channel in Golang?
05:30 Example 1: channels in Golang
06:40 Example 2: channels and goroutines in Golang
08:35 What is a buffered channel in Golang?
09:56 Example: buffered channels in Golang
11:39 Channels: Close, Select and Range in Golang
12:33 Example: goroutines and channels in Golang
17:12 Conclusion: Introduction to Concurrency Patterns in Golang

---

Who am I:

Hello👋🏼! I'm Mario, a Hands-on Software Architect and Lead Backend Engineer with more than 16 years of professional experience building all kinds of software including on-premise Industrial Automation Systems, Linux Accessibility Desktop and Browser Components as well as Distributed Advertising Microservices.

Every week I will share with you different topics I've learned while working for small startups and large companies including the processes I've followed over the years for successfully delivering complex enterprise systems from start to end.

Subscribe if you like Software Development, Software Architecture and Systems Design!

Keep it up. Don't give up!

#golang #tutorial #concurrency

--- Our affiliate links below

--- Our Vlog Channel

[suprecam]

Hey Mario, thanks for the video! Your explanations are not hurried and barebones like most out there, and I have no trouble following along and grasping the concepts immediately. You're a great teacher.

[saadati]

Thanks for explaining the abstract concepts first before showing how they are done in Go. That helped a lot.

[worklife]

Watched 5 of your videos now! These are so good, please please please keep them coming!

[henriquealexandreh]

I like your explanation. It's concise and the examples illustrate well what you mean.
Thanks.

[redamadjoub]

Best explanation about concurrency and parallelism.
Congrats !

[alialiyev]

At 09:50 I think text should say receiving is blocked when buffer is empty, not full. Thanks for video and explanation regardless.

[fruedal]

Amazing work Mario! Just found out about your channel! Keep the amazing work

[benchlb]

Excellent explanations! Thank you Mario

[yuxiang]

Great content! Thanks for sharing. Very helpful!

[devjeff]

Thank you ! You explained it brilliantly

[ahsanjaved]

Thank you, Mario you explained it nicely!

[michaeldausmann]

Hi Mario, thanks for making your content available. I hadn't come accross channels before this and the basic idea made sense. I did find the rest of the concepts it a little overwhelming tho, might come back to this after looking at some other content.

[iarbainaltainvantdevara]

Hi Mario and thanks for the video! One question: in the examples with select and range, you are creating a buffered ch of len 2. However, this is able to receive 5 values, not like the previous example where it would not receive anymore once the number of values sent exceeded the buffer len. How is this possible?

[tony-go-code]

Hi Mario, first as always, thanks for your knowledgeable content. I have 1 question and it's kind of curious on how concurrency works in Docker container? are we sacrificing the concurrency if we put our go application into container? i wish it not, if so could you share how to experiment go concurrency within Docker container? hope to see your video soon on this. #go, #concurrency, #docker

[IPHoldings]

Good video! Only suggestion is that since you're using VIm it's difficult to follow along the line numbers.

[anamikavarshney]

Hi Mario, thanks for creating such content, but I did not find much clarity in the explanation, there is a good scope for improvement, maybe it can be made more verbose and it'd be good if fumbling is reduced.

[thachnnguyen]

As always, good and to the point. However, up till this point, I still don't see a good example from your videos illustrating the difference between unbuffered and buffered channels. For example (except for the panic thing, but who does that?), I can just make the channel in the last example (05-chose-range-select) unbuffered and it works just fine. Different but fine, in the sense that the producer block transfers data to the consumer block. (The order of the print out may be out of order, but that's because I/O ops are slow, not because of something nondeterministic.)

The only reason I've come across is buffered channel is async (still haven't seen a good use case that illustrates it). That is, in your example, unless the producer produces things in some nondeterministic order, there's no need to use a buffered channel.

[yakhoubakeita]

At 9:47 I guess you mean receiving will block when the channel is empty...