Buffered VS UnBuffered Channels In Golang

► Join my Discord community for free education 👉 / discord
► Become a Patreon for exclusive tutorials 👉 / anthonygg_
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
In this Golang tutorial, I'm going to teach you the main difference between buffered and unbuffered channels in Golang.
#golang

[@anthonygg_]

► Join my Discord community for free education discord.com/invite/bDy8t4b3Rz ► Become a Patreon for more exclusive content www.patreon.com/anthonygg_ Thanks for watching

[@jondoe79]

Anthony is a pinnacle of golang. Short, functional, completely effective and right to the point

[@shadowfaxenator]

The main point of buffered channels is not to solve dead lock issue, if you use different goroutines to write and read from a channel you’ll never get a deadlock, but what a buffer can help you is to control the amount of consumers (goroutines) to process channel values. This can be used for example to protect your program from goroutine overflow, or make it more efficient to use an exact amount of cpu cores == num of goroutines if you want to process CPU bound tasks from channels.

[@anthonygg_]

True

[@okhrimenko]

Anthony, IMHO it's worth to mention, that buffered channels have send and receive queues, but unbuffered ones tries to write the value directly from sender to receiver. And if there's no receiver during send operation it just panics.

[@TomDoesTech]

This was awesome! From what I understand, you're right, it's best to start off from an unbuffered channel and then create a buffered if/when you need it.

[@thanhdatvo0]

Please correct me if I'm wrong here: One reason to use buffered channel is because we want to cancel other goroutines, using context.Done(), or context.Err(), if there is a error happens in one goroutine. At this point in time, for the buffered channels, because they don't need to be close, so any go routine use buffered channel could be stopped, by calling return. For unbuffer channels, you have to close all channels after checking context.Done() or context.Err() not nil, so that go routines that wait for unbuffered channel could be stopped. The interesting here is that since there could be mutilple checking points for context.Done() or context.Err() in one go routine, for unbuffered channel, you have to repeat a lot of channel closing code, while for buffered channel, you just simply return, to close that go routine. I am just new to go routine and using context to cancel go routine, and this is what I observed.

[@alexandrucomanescu9857]

A few weeks ago I had some thoughts to start learning Go. Your videos help a lot, so that's what really motivated me.

[@anthonygg_]

Keep going my man!

[@thanhdatvo0]

I'm also so hungry when hearing you talking about cookies :D

[@sfincione2000]

Maybe the answer to the "how big does the buffer param number need to be?" question is, like you said, depending on how long you expect the writing to the channel to be going on before you get consumers on the other side. For example, if you know how many consumers you have, use that number as the value in your channel.

[@cafebean]

my guy eradicated the cookie pox like it's nothing

[@tawseefbhat977]

thanks for this tutorial on golang... need to know about mutex

[@anthonygg_]

Think I have video on that

[@sovrinfo]

Awesome, Big Thanks!

[@sirajul-anik]

Cookie example 💯💯

[@issm6685]

buffered channel life is easy. put a cookie and call it a day!

[@alexmeh1919]

👍👍👍

[@manojsinghnegi1565]

Got it Master 😅

[@prajapati_omkar]

Anthony GG build Complete Backend in Go Fiber framework, so that we can compare with weavebox.

[@melvinkimathi8924]

First viewier :)