Learning Golang: Introduction to Concurrency Patterns, goroutines and channels

[@suprecam9880]

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.

[@MarioCarrion]

Thanks for the feedback. I appreciate it, take care.

[@saadati]

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

[@worklife76]

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

[@MarioCarrion]

Hello. Thanks for the support. Take care.

[@henriquealexandreh]

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

[@MarioCarrion]

Thanks Henrique, cheers!

[@redamadjoub]

Best explanation about concurrency and parallelism. Congrats !

[@MarioCarrion]

Thanks for watching! Cheers

[@alialiyev5892]

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

[@mailman2097]

yes indeed..

[@fruedal]

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

[@MarioCarrion]

Thanks Felipe! Cheers!

[@bench500lb4]

Excellent explanations! Thank you Mario

[@yuxiang4218]

Great content! Thanks for sharing. Very helpful!

[@MarioCarrion]

Thanks for watching! I'm glad you find the context useful. Take care.

[@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?

[@MarioCarrion]

Hi! The size of the buffered channel indicates how many values it can receive before it blocks. Receives will still block when the channel is empty. One way to demonstrate this is by updating the send in the goroutine; instead of sending one value, try sending three. You will notice it blocks after two, adding some fmt.Println will make it clearer.

[@devjeff3192]

Thank you ! You explained it brilliantly

[@ahsanjaved9524]

Thank you, Mario you explained it nicely!

[@michaeldausmann6066]

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.

[@MarioCarrion]

Hey Michael, thanks for watching. Take care.

[@mohokhachai]

Cool

[@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

[@MarioCarrion]

That's a great question, my understanding is that in Docker concurrency depends on how we run the container, so if the container is running with limited "CPUs" then that will affect the program, I believe that also depends on the cloud provider and their own definition of "CPU". I'll run a few experiments and get back to you.

[@roberto_camp]

fantastic!

[@LIFEIS702]

Thanks great video

[@MarioCarrion]

Thanks for watching, cheers

[@IPHoldings]

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

[@MarioCarrion]

Yeah, I've received that feedback before; in recent videos I'm trying to be much explicit with everything to make the content clearer. Thanks!

[@zakariachahboun]

good thanks

[@anamikavarshney28]

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.

[@MarioCarrion]

Hey Anamika, thanks for the feedback. Take care.

[@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.

[@MarioCarrion]

Hello Thach, thanks for the comment. I haven't really covered the use cases regarding using buffered and unbuffered channels but you bring a good point and I think I should cover that in the near future because it's important to understand when/how to use buffered/unbuffered channels. Best

[@thachnnguyen]

@@MarioCarrion Thanks. If you can, a video that explains the fine points of channel would be perfect. Like a goto reference when someone needs to find out something about channels. Here's why. I think Go is a really easy language, but I still don't have the confidence when it comes to channels. For example, I still haven't figured out a deadlock error message that I've got even though there doesn't seem to be any error as far as I can see. I think I still don't understand fully exactly how select or range works (my bug is probably related to it). Your coverage of the different concurrency patterns is great, btw.

[@yakhoubakeita6132]

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