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.
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 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
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!
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!
This was actually really good. Very good but I had to watch it a couple times. Great work!
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!
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
I view this video three times, this should be viewed by all golang developer.
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..
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
Wow, this is a really great talk. Exactly what I wanted to listen to.
Way cool explanation. The best teacher. W'd luv to see more explanations from here.
there is a 1 element lifo as well for performance benefits
Kavya has become a synonym for Channel
Very well done. Thanks for this amazing contribution.
I highly appreciate your great and informative explanation Kayva Joshi .
Great talk. Learned lots of useful things. Great formatting. I could see all the details of the slides on my 13" screen
Really great job at explaining a relatively complex topic in an easy to understand and fun way. :)
I have just started playing with channel. Thanks for this talk 👍
great; expect more talks
It is helpful to me extremely
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
Brilliant talk. Learnt a lot.
Rob Pike and Kavya Joshi do best go talks. Change my mind.
Does anyone know where can I get the slides？
Quite an interesting intro to the channel mechanism.
Great explanation of channel mechanics!
where is the pre？
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?
Excellent material and presentation, thanks you.
awesome and simple talk!
Great talk, got the clear understanding of channels now. Must watch for other gophers.
Great talk! Thanks, Kavya Joshi!
Loved this!
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.
Great Talk!! Thank you for such an insight into Go Channels
I'm always wondering what sort of people downvote a video like this.
me too
Alphabetically sorted people?
C++ devs
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! This topic is interesting and useful!!
Excellent , i know the channel a lot that i ever have
Great talk, I finally understand GO Channels :)
just the best
Great talk! One of the best!
Really awesome talk
great presentation!
Really enjoyed this explanation; thanks!
really amazing talk !
Great talk
Many thanks!
Excellent talk.
Great talk! Thank you so much!
awesome
Cool thanks 👏
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) :)
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
Great talk, thank you so much
At th-cam.com/video/KBZlN0izeiY/w-d-xo.html right hand side func worker(ch) should have *task :=
Thanks, so clear
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!
great talk ....
It is a great talk! Thanks!
so a unbuffered goroutine can create unlimited tasks in the channel?
The style is a bit too cheesy but the contents is very interesting.
Ok. That go routine modifies stack of the other, for performance to do the trick.
.
.
.
.
.
.
.
.
(searches how to learn rust faster)
Great!
This is such an amazing talk/
gdd
Why does she sound so aggressive?
Fantastic talk
Great talk!
Great talk!
great talk!