1:35 I believe that there is a typo and line "ch := make(chan Task, 3)" should be replaced by "taskCh := make(chan Task, 3)". Also worker function should be defined by "worker(taskCh chan Task)".
This is such an amazing talk, makes clear inner working of channel. This will help to write concurrent codes more better way than I am doing today in go
If we are multiplexing g1 and g2 on one os thread arent we at the mercy of the scheduler , for e.g. we can just execute g1 enqueue forever if the channel is not full and no work is done Ofc this is assuming one os thread, does go have enough context not to use the same thread? @google
in case of early reader, G1 decides to write directly to G2 memory location, how does it resume the G2? also how does it tell G2 not to read from buffer? the pending instruction in G2 is to read from buffer right?
Seriously, the question is still "why channel?" versus the simple use of a mutex? They're both blocking. If channels block everywhere, obviously using a mutex is clearly better. All channels do is to move the isolation from one place (which can be a bottleneck) to another (a smaller bottleneck). All the "cool" things mentioned aren't cool, just necessary things not to block everywhere. What would be cool is what makes channel a communication means preferred over mutex.
A channel is a higher-level construct compared to a mutex, which is low-level and it is too easy to use them in a wrong way - lock/unlock them in a wrong order, forget to lock/unlock and so on. With channels you can solve simple tasks in a simple way. And most importantly, you can compose these solutions without introducing much complexity. Sure, you can rewrite any code by replacing channels with mutex-guarded queues (and even cut some corners to get better performance) but there is a Go proverb "Don't communicate by sharing memory, share memory by communicating" for a reason - for most Go programmers the mental tax of using mutex is higher.
this is a great talk thanks but I don't like calling things "magic", actually we amaze me about go it is reasonably easy to understand what will the code does
The concepts she describes could be applied by you. Also, not everything needs to be usable on daily basis. Learning is a construction - with this video you got some blocks. Save them for the future (that might be tomorrow) :)
This is a great talk; I would never have imagined finding a talk about "the inner workings of channels and channel operations" so interesting.
She explained the implementation of channel in such a understandable way, great talk!
This was actually really good. Very good but I had to watch it a couple times. Great work!
One of the best Go talks I’ve ever seen! Great explanations. Love the enthusiasm.
I find this behind-the-scene explanation is the best way to explain channels. It removes the magic and makes it easier to understand. Thank you!
Such a complex topic explained in a such a simple manner. Really a great talk
this is the best talk ever on concurrency and channels, Thanks Gopher Academy and Kavya Joshi
Must watch for every gopher out there!
I view this video three times, this should be viewed by all golang developer.
1:35 I believe that there is a typo and line "ch := make(chan Task, 3)" should be replaced by "taskCh := make(chan Task, 3)". Also worker function should be defined by "worker(taskCh chan Task)".
yep, was thinking about the same
+1
Thanks for the amazing informative content Gopher Academy. The speaker explained everything in very detailed crisp and with nice presentation.
The structure and concepts behind goroutines and channels are presented in a very nice & simple manner. Thanks for this great talk, Kavya!
Kavya Joshi -done it in an understanding manner...presentation slides was also superb..
Wow, this is a really great talk. Exactly what I wanted to listen to.
This is such an amazing talk, makes clear inner working of channel. This will help to write concurrent codes more better way than I am doing today in go
Way cool explanation. The best teacher. W'd luv to see more explanations from here.
Great talk. Learned lots of useful things. Great formatting. I could see all the details of the slides on my 13" screen
great; expect more talks
Very well done. Thanks for this amazing contribution.
Really great job at explaining a relatively complex topic in an easy to understand and fun way. :)
I highly appreciate your great and informative explanation Kayva Joshi .
I have just started playing with channel. Thanks for this talk 👍
there is a 1 element lifo as well for performance benefits
If we are multiplexing g1 and g2 on one os thread arent we at the mercy of the scheduler , for e.g. we can just execute g1 enqueue forever if the channel is not full and no work is done
Ofc this is assuming one os thread, does go have enough context not to use the same thread?
@google
Great explanation of channel mechanics!
Brilliant talk. Learnt a lot.
Loved this!
Quite an interesting intro to the channel mechanism.
Excellent material and presentation, thanks you.
in case of early reader, G1 decides to write directly to G2 memory location, how does it resume the G2? also how does it tell G2 not to read from buffer? the pending instruction in G2 is to read from buffer right?
It is helpful to me extremely
Kavya has become a synonym for Channel
awesome and simple talk!
Great Talk!! Thank you for such an insight into Go Channels
Great talk! This topic is interesting and useful!!
Great talk! One of the best!
Seriously, the question is still "why channel?" versus the simple use of a mutex? They're both blocking. If channels block everywhere, obviously using a mutex is clearly better. All channels do is to move the isolation from one place (which can be a bottleneck) to another (a smaller bottleneck). All the "cool" things mentioned aren't cool, just necessary things not to block everywhere. What would be cool is what makes channel a communication means preferred over mutex.
A channel is a higher-level construct compared to a mutex, which is low-level and it is too easy to use them in a wrong way - lock/unlock them in a wrong order, forget to lock/unlock and so on. With channels you can solve simple tasks in a simple way. And most importantly, you can compose these solutions without introducing much complexity. Sure, you can rewrite any code by replacing channels with mutex-guarded queues (and even cut some corners to get better performance) but there is a Go proverb "Don't communicate by sharing memory, share memory by communicating" for a reason - for most Go programmers the mental tax of using mutex is higher.
Does anyone know where can I get the slides？
Rob Pike and Kavya Joshi do best go talks. Change my mind.
Great talk! Thanks, Kavya Joshi!
Excellent , i know the channel a lot that i ever have
Wish she had written a book..Or is there such a book about internals of Go concurrency primitives.
evanson mwangi Why? There's nothing to say about this more. Really. It's that simple. The rest of the details are in the Go source code.
Great talk, I finally understand GO Channels :)
Great talk, got the clear understanding of channels now. Must watch for other gophers.
Really enjoyed this explanation; thanks!
I'm always wondering what sort of people downvote a video like this.
me too
Alphabetically sorted people?
C++ devs
great presentation!
Really awesome talk
just the best
where is the pre？
really amazing talk !
Great talk! Thank you so much!
Excellent talk.
Many thanks!
awesome
Great talk
Cool thanks 👏
cool
yup, this is pretty cool
this is a great talk thanks but I don't like calling things "magic", actually we amaze me about go it is reasonably easy to understand what will the code does
When you said Go multiplexes the goroutines onto the OS main threads, isent context switching invovled?
I think it's more SJ LJ or trampoline style context switching, all just userspace function calls. Not as expensive as getting the OS involved.
Great talk, thank you so much
The style is a bit too cheesy but the contents is very interesting.
How the knowledge here helps us on daily basis? I haven't watched the video yet, but the deep explanation upfront is so hard to follow.
The concepts she describes could be applied by you. Also, not everything needs to be usable on daily basis. Learning is a construction - with this video you got some blocks. Save them for the future (that might be tomorrow) :)
Thanks, so clear
Great talk!
It is a great talk! Thanks!
great talk ....
At ua-cam.com/video/KBZlN0izeiY/v-deo.html right hand side func worker(ch) should have *task :=
Great!
so a unbuffered goroutine can create unlimited tasks in the channel?
Ok. That go routine modifies stack of the other, for performance to do the trick.
.
.
.
.
.
.
.
.
(searches how to learn rust faster)
gdd
This is such an amazing talk/
Why does she sound so aggressive?
Fantastic talk
Great talk!
Great talk!
great talk!