Excellent presentation! One of the best I have watched about Go, without a doubt the best about concurrency in Go and a great sequel to Rob Pike's "Concurrency is not Parallelism". Good thing I didn't watched it live, because I wouldn't been able to understand the code examples right there without a pause button. But that was a good thing: less time explaining how the examples work and more about why they work makes it a great presentation.
Yes! I was there and I admit that I didn't completely grok it. It is one of those talks that gets better with every listen and has become my favorite talk so far.
Great talk, thanks Bryan. The examples were helpful, and I found your pauses well-timed to allow me to absorb what you were communicating, by sharing the ideas :-)
Hey Bryan, why do you need second for loop in 33:17 semaphore pattern? The above code is already blocking until all tasks are performed and number of running in parallel goroutines limited by `limit` parameter of buffered channel.
The loop is there to wait for the completion of the last worker goroutine. Once the last item of hugeSlice has been read, the last goroutine is started and the main goroutine goes on immediately since the first loop has ended.
What's the reason for having "c net.Conn" as an argument of Hijack at 16:45 if it is not used in the body? The same at 17:59 when the function is implemented using channels.
The call to `Hijack` is intended to record that a specific connection has been permanently removed from the pool. The (unused) argument makes it possible to add more diagnostics that don't fit on the slide in order to verify correct use - for example, the Hijack method could check that the specific Conn was actually acquired from the pool, the Release method could verify that a Conn is not returned to the Pool after it has been hijacked, and a finalizer on the Pool could verify that every connection returned by Acquire is ultimately either hijacked or released back to it.
The code for better worker pools at 33:06 relies on goroutines being unblocked in FIFO order, which isn't guaranteed by the Golang spec (although is the current implementation).
It shouldn't depend on anything being FIFO - that's one of the reasons the semaphore-acquire should happen before the `go` statement (instead of inside the goroutine).
While I really like the material he shows, his presentation is awful, he is reading his notes the whole time and it is like a robot repeating what the notes said, it will be hundred times better if we just get the slides and notes and read it from there, seriously, I tried to watch this and it was impossible thanks to his awful presentation style.
I agree. Just live code it and struggle through so we can learn the real thought process. I don't need to see the guy and a massive gophercon banner either. Fullscreen coding. Code had no comments. If you sat through that you got almost nothing out of it. You have to pause and rewind and run the code in your head line by line. He should be able to run a live example to show what's going on. Print stuff out or run the debugger.
Terrible presentation. Code examples are too confusing and the presenter too robot-like. I've been using Go for years and I had to pause the video multiple times to try and understand what was being said and what was being shown. The code is terrible.
TERRIBLE! ... Very difficult to understand. Fullscreen on the code. Put comments on your code or explain it line by line. I don't need to see Gophercon and a PIP of a wooden presenter. The info is good if you rewatch it and pause and rewind multiple times. Presentations are to teach and not show you're smart. Live coding is best.
The code doesn't need comments. You need to be able to wrap your head around the possibilities of channels and goroutines, then it's obvious. That's a thing you have to learn, and analysing this code is a good way to do that.
This talk must have been hard to digest live, but it's great on replay. So underrated!
Excellent talk!! I replayed it quite a few times to understand the dense content, but felt it was worth the time.
6 years later this is still evergreen
Excellent presentation! One of the best I have watched about Go, without a doubt the best about concurrency in Go and a great sequel to Rob Pike's "Concurrency is not Parallelism". Good thing I didn't watched it live, because I wouldn't been able to understand the code examples right there without a pause button. But that was a good thing: less time explaining how the examples work and more about why they work makes it a great presentation.
Yes! I was there and I admit that I didn't completely grok it. It is one of those talks that gets better with every listen and has become my favorite talk so far.
Great talk, thanks Bryan. The examples were helpful, and I found your pauses well-timed to allow me to absorb what you were communicating, by sharing the ideas :-)
Hey Bryan, why do you need second for loop in 33:17 semaphore pattern? The above code is already blocking until all tasks are performed and number of running in parallel goroutines limited by `limit` parameter of buffered channel.
The loop is there to wait for the completion of the last worker goroutine. Once the last item of hugeSlice has been read, the last goroutine is started and the main goroutine goes on immediately since the first loop has ended.
I need rewrite my concurrency code after watching this video.
What's the reason for having "c net.Conn" as an argument of Hijack at 16:45 if it is not used in the body? The same at 17:59 when the function is implemented using channels.
The call to `Hijack` is intended to record that a specific connection has been permanently removed from the pool. The (unused) argument makes it possible to add more diagnostics that don't fit on the slide in order to verify correct use - for example, the Hijack method could check that the specific Conn was actually acquired from the pool, the Release method could verify that a Conn is not returned to the Pool after it has been hijacked, and a finalizer on the Pool could verify that every connection returned by Acquire is ultimately either hijacked or released back to it.
Hello Bryan,
At 21:21, or page 63 of the presentation, could the q.empty channel be replaced with Select {Default : } instead of Select {case
novel, clear & concise. thanks
Too much to digest for a lunch break, I need to come back again later
What does the slice notatatoin slice[:n:n] do?
Trigger a syntax error.
it sets the capacity of the new slice. Otherwise the same capacity as the origin slice will be allocated, which is not optimal.
pdf can be found here - drive.google.com/file/d/1nPdvhB0PutEJzdCq5ms6UI58dp50fcAN/view
The code for better worker pools at 33:06 relies on goroutines being unblocked in FIFO order, which isn't guaranteed by the Golang spec (although is the current implementation).
No it doesn't.
It shouldn't depend on anything being FIFO - that's one of the reasons the semaphore-acquire should happen before the `go` statement (instead of inside the goroutine).
Great talk, that changes how one writes/views concurrent code.
Excellent talk
The worker pool is genius.
I know, I wasn't really interested in the Cond stuff, but that workerpool blew my mind. Beautiful.
In this talk, Bryan argues that the semaphore pattern should be favoured over the worker-pool pattern, though.
Please consider dark background, will be easier to watch.
Sync API, share by communication... Fully usage of Channel can be benefit but challenge...
Too hard to understand :(
Then you shouldn't be here. Learn basics.
While I really like the material he shows, his presentation is awful, he is reading his notes the whole time and it is like a robot repeating what the notes said, it will be hundred times better if we just get the slides and notes and read it from there, seriously, I tried to watch this and it was impossible thanks to his awful presentation style.
you're being hyperbolic
I agree. Just live code it and struggle through so we can learn the real thought process. I don't need to see the guy and a massive gophercon banner either. Fullscreen coding. Code had no comments. If you sat through that you got almost nothing out of it. You have to pause and rewind and run the code in your head line by line. He should be able to run a live example to show what's going on. Print stuff out or run the debugger.
It's not awful. It's Shakespearean!
To block, or not to block, THAT is the question.
The speaker is smart but the presentation of the different topics was really poor.
Terrible presentation. Code examples are too confusing and the presenter too robot-like. I've been using Go for years and I had to pause the video multiple times to try and understand what was being said and what was being shown. The code is terrible.
Robot-like yes, but the code is actually genius. Come back in couple of years when you've learned more go, then you'll appreciate it.
@@florenckaf I've been a Go programmer for years and there's nothing genius here.
TERRIBLE! ... Very difficult to understand. Fullscreen on the code. Put comments on your code or explain it line by line. I don't need to see Gophercon and a PIP of a wooden presenter. The info is good if you rewatch it and pause and rewind multiple times. Presentations are to teach and not show you're smart. Live coding is best.
The code doesn't need comments. You need to be able to wrap your head around the possibilities of channels and goroutines, then it's obvious. That's a thing you have to learn, and analysing this code is a good way to do that.
I'm sure you are fun at parties