I became a fan of Peter after viewing another presentation he gave, where he was chased off stage when he was owed TWO MINUTES. Life is unfair. Peter has many great qualities though the ones I like the most are his immaculate hair, pragmatism and authenticity. Good talk.
Very elegant. Thanks Peter. My only concern is on the Group name which I find too generic. Does not convey the essence of what you came up with here IMHO. Here are a few alternate suggestions: ActorGroup.Add[Actor], Team.Add[Player], Orchestra.Add (with .Conduct() instead of .Go()), or finally Ensemble.Orchestrate(play, stop).
Great talk. If you don't care about the first error that orchestrated the shutdown of your app, you can just make `net.Listener` context-aware. For example, one can start a goroutine in an anonymous func that reads from `ctx.Done()` and then calls `listener.Close()`
19:43 I wonder how to do error handling for all the goroutines here. It already needs so many chans just to cancel, so how to add error handling without adding too much mess?
I would like to put these snippets into a text repository I keep for ideas and inspiration and design patterns. Are these talk slides online somewhere or must I type them in from the stills onscreen?
What is the benefit of sending the processing to a separate go routine? The select statement still blocks so it doesn't seem that it makes the request any faster.
My initial thoughts exactly. But then I realised that this is a synchronisation pattern: rather than messing around with mutexes and stuff, we perform all of the operations in a designated goroutine in a sequential manner, so each operation has an exclusive undivided access to data
@24:16 in to the video, your actor launcher should have a channel wait receive within those anon go func calls which execute the actor, and after the loop the wait channel should be closed. Otherwise all of the actors will actually get launched one after the other, not at exactly the same time like that comment block was claiming.
@@aarondavidcooper It's only ever parallel if it's running across multiple physical cores, otherwise it's concurrent/one after the other very quickly. That single line quote from the Go authors doesn't really address any points in my comment though, what's your point?
@@tauraamui The timestamp you provided states "Run all actors (functions) concurrently" which it does, so I replied as it looked like you may have confused concurrency with parallelism based on your suggestion. Sorry you didn't find it helpful, all the best.
@@aarondavidcooper Oh ok, so my point was just that the workers won't all start effectively at the same time, whether or not it's concurrent or parallel isn't part of the point I was trying to make. So if you want multiple routines to begin at the same time, you call them with the go invoke one after the other (because that's the only practical way to do that), but within the routines you immediately block them all by reading on an empty channel, but once they've all been Go invoked you then close that channel. When I said they don't all start at the same time, I wasn't referring to transparent difference between concurrent or literally the same time of parallism
Thanks for the comment. Even with a synchronization "fence" as you suggest, there's actually no guarantee the goroutines will start at the same time -- the scheduler is inherently nondeterministic in this regard! So I think there's really no practical difference between the current implementation and your suggestion.
I became a fan of Peter after viewing another presentation he gave, where he was chased off stage when he was owed TWO MINUTES. Life is unfair. Peter has many great qualities though the ones I like the most are his immaculate hair, pragmatism and authenticity. Good talk.
"give more control to the caller"
This is one of my favorite software idioms.
UA-cam, how can I upvote this video twice? Behind a painfully generic title hides a great talk!
Concise, precise amd to the point. I like such well thought sessions.
Very elegant. Thanks Peter. My only concern is on the Group name which I find too generic. Does not convey the essence of what you came up with here IMHO. Here are a few alternate suggestions: ActorGroup.Add[Actor], Team.Add[Player], Orchestra.Add (with .Conduct() instead of .Go()), or finally Ensemble.Orchestrate(play, stop).
Great talk. If you don't care about the first error that orchestrated the shutdown of your app, you can just make `net.Listener` context-aware. For example, one can start a goroutine in an anonymous func that reads from `ctx.Done()` and then calls `listener.Close()`
Thank you, Skinny Pete.
19:43 I wonder how to do error handling for all the goroutines here. It already needs so many chans just to cancel, so how to add error handling without adding too much mess?
Brilliant as always
I would like to put these snippets into a text repository I keep for ideas and inspiration and design patterns. Are these talk slides online somewhere or must I type them in from the stills onscreen?
The url at 22:45 wasn't quite right but it can be found here: github.com/oklog/run
What is the benefit of sending the processing to a separate go routine? The select statement still blocks so it doesn't seem that it makes the request any faster.
My initial thoughts exactly. But then I realised that this is a synchronisation pattern: rather than messing around with mutexes and stuff, we perform all of the operations in a designated goroutine in a sequential manner, so each operation has an exclusive undivided access to data
@24:16 in to the video, your actor launcher should have a channel wait receive within those anon go func calls which execute the actor, and after the loop the wait channel should be closed. Otherwise all of the actors will actually get launched one after the other, not at exactly the same time like that comment block was claiming.
concurrency is not parallelism
@@aarondavidcooper It's only ever parallel if it's running across multiple physical cores, otherwise it's concurrent/one after the other very quickly. That single line quote from the Go authors doesn't really address any points in my comment though, what's your point?
@@tauraamui The timestamp you provided states "Run all actors (functions) concurrently" which it does, so I replied as it looked like you may have confused concurrency with parallelism based on your suggestion. Sorry you didn't find it helpful, all the best.
@@aarondavidcooper Oh ok, so my point was just that the workers won't all start effectively at the same time, whether or not it's concurrent or parallel isn't part of the point I was trying to make. So if you want multiple routines to begin at the same time, you call them with the go invoke one after the other (because that's the only practical way to do that), but within the routines you immediately block them all by reading on an empty channel, but once they've all been Go invoked you then close that channel. When I said they don't all start at the same time, I wasn't referring to transparent difference between concurrent or literally the same time of parallism
Thanks for the comment. Even with a synchronization "fence" as you suggest, there's actually no guarantee the goroutines will start at the same time -- the scheduler is inherently nondeterministic in this regard! So I think there's really no practical difference between the current implementation and your suggestion.
Genious.
Useful talk
Very useful!
+1 for Group, first 10 minutes are bit boring, overall very good talk