loved the last question: "if my routine is deadlocked, will it stay like that?", i mean, he gave fairly good number of examples of how timeout such things.
The question did state "and I don't have a timeout". Another asker followed up later with the same question. What happens if a writer writes to a channel and no one ever reads from it. From what I can gather in Go is that you simply "Don't let it happen". If you need to make a dynamic decision on a channel, you need to have the signal passed across, or use a buffered channel.
Excellent talk. Something that always bothered me about Go is the horrible nomenclature for things: - Alright, this is the syntax, what do you think? - What's "chan" - Oh, that's a channel - Why not calling it "channel" then? - We save 3 characters in the source code. - And "func" is a function, right? - Correct - Why not "function" ? It is only 4 more - Four more is a LOT! - Alright, how about "str" instead of "string" ? You'd have way more string declarations than functions - Hmm...naaaah, string would be clearer to read.
Thank you for such a great presentation! The concurrence examples were exactly what I was looking for, and convinced me to start learning Go today. Might you consider using concise file reading and parsing like in AWK? Thanks.
Though go is a static language, it can be so powerful that it has elegant grammar and better concurrency capability that make us write less yet robust code
I hope google goes with go (golang) as the new official language for android development, it will be the most assertive choice. This will be the big “Nextstep” for android ;)
I hope google realizes their err and goes back to Java. The most readable of the bunch. Kotlin is a notch more repulsive than go, but they’re both terrible
I was trying to follow this along on my local, an interesting finding at 18:06 , in the fanIn function when you spawn two anonymous goroutines, if you don't use for loop around c
@25:23 This seems like an anti pattern, because both go routines (the parent and the child) play the role of sender and receiver on the quit channel. Seems to me, you generally want one go routine to only send, and the other to only receive (on the same channel). In this case, seems to make the most sense that the parent go routine is the sender (on the quit channel) and the child only receives (again, on quit). To make the parent block on cleanup returning, you'd have a third channel: done_cleaning_up, which (in addition to c, the primary result channel) gets returned by boring. I know that's 50% more channels than the design shown, but I feel that more channels is preferable vs. overloading quit. If we could change the language slightly, another way to make this nicer is if the receiver had the ability to close a channel (Go only allows the sender to do this), because then, instead of using quit to signal from the parent to the child that no more values are wanted via c, the parent simply closes c, and the send in the child would fail.
@31:56 The loop in the second half of this example is funny, because there is a magical number in there (i < 3), which you have to remember to update if you add something like Shopping. I think in other languages, you would join all the threads (or in this case, go routines). Unfortunately, go routines have no handle on which to join.
Yeah it's a trick. Formally you need a wait group and a new goroutine to wait all the searching goroutine to finish, and then close the channel. And in main goroutine, you can use a for-range on the channel. The lecturer just tried to avoid the using of waitgroup 'cause it's gonna be a distraction.
@@kevinchou9155 No, actually all the search functions have all the same signature, you could collect them in a slice and spawn them off as Go-routines in a for-loop. Then the second for-loop iterates the same number of times as the length of the slice. (i.e the same number as the number of search functions). You don't have to close a channel in order for it to be garbage collected, as soon as a channel goes out of scope and is not referenced it will get garbage collected. It's clearly stated in the language documentation. There is no need for a wait-group. If you need to signal a consumer that the producer is done, then you can do it by closing a channel,- or if you iterate over a channel with a for-loop, ( for element := range channel { ...} ), you need to close the channel in order to end the for-loop.
In the fanIn part, isn't it just unnecessary to make some sort of separate proxy function for them when we can just modify the boring function to take in more than one param and function just like a multiplexer, while the fmt.Println() function prints whatever value it gets first from the boring function
If you are talking about the fanIn with two goroutines vs with only one: he said it is equivalent, just a different way to express the same idea. p.s.: if you meant that the fanIn function is not necessary, simply inline it, it could be done for both too, I think.
@19:32 I do not see the point of these wait channels. If you want to alternate between the two original channels, don't be using fanIn to mix things up in the first place!
Rob expands on his comment at the end of this about blocking goroutines, that won't return, being garbage collected, saying the goroutines do need to return, otherwise they will be a leak. time.After solves this by using a buffered channel, so even if the channel is not being read, it will return, and if there's no other reference to the channel after time.After returns, the channel is garbage collected. groups.google.com/forum/m/#!topic/golang-nuts/bfuwmhbZHYw/discussion
So regardless of whether I use the fanIn function with two goroutines or the select statement (and copying the code straight from a copy of the slides) -- if I run the sleep with 'rand.Intn(1e3)' I always see Joe / Ann print in lockstep, and if I run it with 'rand.Intn(1e2)' I always see a pattern of 0,0,1,1,2,2,3,4,3,5 (sometimes Joe gets to 5, sometimes Ann does). I've ran it numerous times and never seen a deviation from this. Unless I'm mistaken -- this isn't the expected behavior. What's going on here?
@@zerosandones701may be "Note: The environment in which these programs are executed is deterministic, so each time you run the example program rand.Intn will return the same number. (To see a different number, seed the number generator; see rand.Seed. Time is constant in the playground, so you will need to use something else as the seed.)" from tour.golang.org/basics/1
The main idea is about creating 10000 blocked goroutines, each copies value from the right channel to the left channel. The creation sequence is from the last channel(leftmost) to the first one(rightmost). In each creation procedure, after finished creating the goroutine, the left channel is no longer needed, and the right channel becomes the left channel we will need in the next iteration, so we made the right become the left for next iteration during which a new right will be freshly made. After the creation completes, all 10000 goroutine are blocked, since no value is sent through the first(rightmost) channel. Then we sent a value, and the value get passed through all the channels and goroutines. The key point is that the whole procedure is really fast with go considering the total numbers of the goroutines. So goroutine is realy light-weighted.
Hi from 2024! I met some difficulties in understanding of this code part, so I decided to rewrite one a little bit and add comments for better understanding. Here it its: func main() { n := 100000 // In Rob's code `right` variable has been initialized as `right := leftmost` // However, it rewrites every time in for-loop below, so we don't have to initialize `right` here (what a pan!) // But we have to keep visibility of this variable within the main function because we have to call it after for-loop // The clearest way for us is to declare `right` variable here without initialization var right chan int leftmost := make(chan int) left := leftmost // I spent a lot of time to get the one simple point // We're building a chains here from left to right // Not from right to left as you can see in the picture with Gophers // Don't be fooled by arrows direction for i := 0; i < n; i++ { right = make(chan int) go f(left, right) left = right } // I rewrite this code a little bit // It's clearer for me than the Rob's code // Just put a 0 to the rightmost channel to start the whole process go func() { right
FYI: The example here ruclips.net/video/f6kdp27TYZs/видео.html does not work, runs forever. Had to refactor to use this: timeChannel := time.After(1 * time.Second). Go version: 1.14
Alex George All concurrency implementation problems arise from threads accessing shared memory at the same time. Go takes a different approach by passing around memory to channels therefore providing implicit locking in a sense.
This video confused the hell out of me. So many assumptions and skipping steps. I’m left with at least an order of magnitude more questions than when I came in.
waitForIt = make(chan bool) Shared between all messages(struct), so all goroutines will wait for bool message from "waiForIt chan" after finishing its own tasks. Then if the main function sends a bool to the shared "waiForIt" channel, which goroutine will get the bool first? it still could keep the sequence in order?
I think you better do what you have all the characteristics of all programming languages only it is activated and enable des modes because by eliminating pointer index it increases security but loses dynamic processes ingenious little suspect. better have all the features including haskel but the default is to show and recommend, is concerned activate other types of programming to be even more popular and more free ... !!!
+babu OO creo que lo mejor es hacer lo que tenga todas las características de todos los lenguajes de programación solo que se activa y se des activa las modalidades porque al eliminar los el indice de puntero aumenta la seguridad pero pierde dinamismo de procesos ingeniosos poco sospechados. mejor que tenga todas la características incluyendo haskel pero el por defecto es la que muestran y recomiendan, es cuestión activar las otras modalidades de programacion para que sea mas popular todavia y mas libre...!!!
Try Go // You can edit this code! // Click here and start typing. package main import "fmt" func main() { fmt.Println("Hello, world") } Same shit in Python : print 'Hello, world' yeah thanks ill stick with python
lol, every single startup that you can find anywhere in europe and us are using go if not node.js . It's really popular for backend related tasks & systems programming. Because it's simple to read yet has all the tools to express something really complex.
Go is a lower level language which actually requires you to know programming, if you want to do stuff. C# and Java is high level programming which compiles as ugly buggy crap.
saying c# and java compile into "buggy crap" is pretty ignorant. You would be hard pressed to find an issue caused by compiling in c# or java. The issue most people have is with the garbage collection (go is also garbage collected by the way) being slow and the fact that memory management is mostly abstracted away. As always though, a language is just a tool, and no one tool is universally the best. There are use cases where using c# (mainly for the .net stuff) or java is better than using go.
There is the perfect language. And its name is Haskell. This language has an almost human AI and it writes code by itself. But the Dark Government is trying hard to keep this language in secret.
Register to save your spot for Google I/O✨➡ goo.gle/io24-yt
Rob's clarity in these talks is next level. Each one I watch gets me more excited about learning Go.
I am a teacher myself and I can see how much work was put in the preparation for this talk. Few weeks probably for 40 minutes talk.
I have been living under a rock, just got into Golang. This language with its concurrency model is mind blowing.
I'm relatively new to programming and was trying to get the hang of multithreading in Go. This video helped a lot. Thank you.
By now, you are probably programming expert.
Are you a super saiyan programmer bro
Highly recommend to watch this video after you read all offical tour for deeper understanding.
I agree. This is what I felt was "missing" from the tour
Go is growing on me more and more. In fact, I'm starting to love it.
@John Markovich Well I do still love it :D
Rob really can explain
Though having seen these patterns when reading open source code before, it's still very helpful to watch this video. Thanks!
The best presentation for Go Concurrency.
Still true. I'm learning Go now, I've watched a lot of videos and read books and this is the best.
Is there any one watching this video in 2024 just like me
这里，差点就到2025年了，🤣
"To make the boring less interesting" what a great sentence.
You're easily impressed
loved the last question: "if my routine is deadlocked, will it stay like that?", i mean, he gave fairly good number of examples of how timeout such things.
The question did state "and I don't have a timeout". Another asker followed up later with the same question. What happens if a writer writes to a channel and no one ever reads from it.
From what I can gather in Go is that you simply "Don't let it happen". If you need to make a dynamic decision on a channel, you need to have the signal passed across, or use a buffered channel.
Excellent talk. Something that always bothered me about Go is the horrible nomenclature for things:
- Alright, this is the syntax, what do you think?
- What's "chan"
- Oh, that's a channel
- Why not calling it "channel" then?
- We save 3 characters in the source code.
- And "func" is a function, right?
- Correct
- Why not "function" ? It is only 4 more
- Four more is a LOT!
- Alright, how about "str" instead of "string" ? You'd have way more string declarations than functions
- Hmm...naaaah, string would be clearer to read.
Thank you for such a great presentation! The concurrence examples were exactly what I was looking for, and convinced me to start learning Go today.
Might you consider using concise file reading and parsing like in AWK? Thanks.
Though go is a static language, it can be so powerful that it has elegant grammar and better concurrency capability that make us write less yet robust code
Less code means more black box magic and opinionated design. It’s painful
I hope google goes with go (golang) as the new official language for android development, it will be the most assertive choice. This will be the big “Nextstep” for android ;)
it would be great and cool!
I hope google realizes their err and goes back to Java. The most readable of the bunch. Kotlin is a notch more repulsive than go, but they’re both terrible
Very clear and concise, right timing too.
Ker-Kling that's the penny dropping for me on channels in Go... Amazing talk
I was trying to follow this along on my local, an interesting finding at 18:06 , in the fanIn function when you spawn two anonymous goroutines, if you don't use for loop around c
@25:23 This seems like an anti pattern, because both go routines (the parent and the child) play the role of sender and receiver on the quit channel. Seems to me, you generally want one go routine to only send, and the other to only receive (on the same channel). In this case, seems to make the most sense that the parent go routine is the sender (on the quit channel) and the child only receives (again, on quit). To make the parent block on cleanup returning, you'd have a third channel: done_cleaning_up, which (in addition to c, the primary result channel) gets returned by boring. I know that's 50% more channels than the design shown, but I feel that more channels is preferable vs. overloading quit.
If we could change the language slightly, another way to make this nicer is if the receiver had the ability to close a channel (Go only allows the sender to do this), because then, instead of using quit to signal from the parent to the child that no more values are wanted via c, the parent simply closes c, and the send in the child would fail.
Is there any one watching this video in 2021 just like me
Hi, I'm from the future...
2024, still a great lecture
2024
Hey guys I heard you like channels so I put a channel in your channel
yo dawg
A good talk, i'm definitely going to learn Go.
Also, about Heroku Waza talk that Rob mentioned, it's not out yet apparently (after 6 months).
23:40 when you click on "Run" again, just to double-check whether you seeded your PRNG with a random value. But you didn't! XD THANK YOU FOR THE TALK!
Awesome presentation!
Great talk, many thanks for publishing it
whoever started learning go concurrency must watch video
Thanks for this Rob
great presentation
A switch isn't made for communication (channels), switch just does value comparison. It is not posible to use use a channel get (myInt :=
@31:56 The loop in the second half of this example is funny, because there is a magical number in there (i < 3), which you have to remember to update if you add something like Shopping. I think in other languages, you would join all the threads (or in this case, go routines). Unfortunately, go routines have no handle on which to join.
Yeah it's a trick. Formally you need a wait group and a new goroutine to wait all the searching goroutine to finish, and then close the channel. And in main goroutine, you can use a for-range on the channel. The lecturer just tried to avoid the using of waitgroup 'cause it's gonna be a distraction.
@@kevinchou9155 No, actually all the search functions have all the same signature, you could collect them in a slice and spawn them off as Go-routines in a for-loop. Then the second for-loop iterates the same number of times as the length of the slice. (i.e the same number as the number of search functions). You don't have to close a channel in order for it to be garbage collected, as soon as a channel goes out of scope and is not referenced it will get garbage collected. It's clearly stated in the language documentation. There is no need for a wait-group.
If you need to signal a consumer that the producer is done, then you can do it by closing a channel,- or if you iterate over a channel with a for-loop, ( for element := range channel { ...} ), you need to close the channel in order to end the for-loop.
what an excellent man
In the fanIn part, isn't it just unnecessary to make some sort of separate proxy function for them when we can just modify the boring function to take in more than one param and function just like a multiplexer, while the fmt.Println() function prints whatever value it gets first from the boring function
Awesome Video!
Amazing language handling the concurrency
Very interesting. Used it in my concurrency class.
damn, 6 years ago..
8.5 years ago
Slides at talks.golang.org/2012/concurrency.slide
great video
Wonderful talk as is the language.
Superb explanation!
I think I know how they've come up with golang logo :)
how i dont get it lol
Wow! :P I never looked at it that way until now. Pure discrimination! :P
this is a great talk. very inspiring.
A remarkable talk
Correct me if I'm wrong, but doesn't the select statement do exactly what he's trying to do with fan-in?
If you are talking about the fanIn with two goroutines vs with only one: he said it is equivalent, just a different way to express the same idea.
p.s.: if you meant that the fanIn function is not necessary, simply inline it, it could be done for both too, I think.
I think current would be a better name for channel, but maybe it's just me ;)
Source code link: talks.golang.org/2012/concurrency/support
Thanks!
The answer to the first question was unclear. So the indeterminism of go routines cannot be mocked and you just mock the service being called ?
@19:32 I do not see the point of these wait channels. If you want to alternate between the two original channels, don't be using fanIn to mix things up in the first place!
Rob expands on his comment at the end of this about blocking goroutines, that won't return, being garbage collected, saying the goroutines do need to return, otherwise they will be a leak. time.After solves this by using a buffered channel, so even if the channel is not being read, it will return, and if there's no other reference to the channel after time.After returns, the channel is garbage collected.
groups.google.com/forum/m/#!topic/golang-nuts/bfuwmhbZHYw/discussion
The answer to the last qn should have been "Now why would you do something like that".
The daisy chain is confusing. how its giving 100001.
Otherwise awesome tutorial.
Re 49:20 -- Instead of nesting, it seems like you could just use a switch statement, I think...
I
This talk scares me about concurrency.
28:50 "and some ads" Rob is humorous
سبانم٧اغزعخع٦لنع٦تت٥ل٥فد٤دثذثذث، ثصظضاخككحةك٠ةجةةكنبفيقتيثس🎉
Lugina e Ujqërve Pjesa VI 1
😢❤🥝😊الله
مشاهدة
So regardless of whether I use the fanIn function with two goroutines or the select statement (and copying the code straight from a copy of the slides) -- if I run the sleep with 'rand.Intn(1e3)' I always see Joe / Ann print in lockstep, and if I run it with 'rand.Intn(1e2)' I always see a pattern of 0,0,1,1,2,2,3,4,3,5 (sometimes Joe gets to 5, sometimes Ann does). I've ran it numerous times and never seen a deviation from this. Unless I'm mistaken -- this isn't the expected behavior. What's going on here?
+AnirudhC Nvm - I see the rand is deterministic, very interesting
+zubie7a Yup that was the issue!
@@zerosandones701 tour.golang.org/basics/1
@@zerosandones701may be "Note: The environment in which these programs are executed is deterministic, so each time you run the example program rand.Intn will return the same number.
(To see a different number, seed the number generator; see rand.Seed. Time is constant in the playground, so you will need to use something else as the seed.)" from tour.golang.org/basics/1
shit flew above my head!
Could somebody tell me how can I get the source code in this presentation? Thx a lot
Maybe on the surface. If you want to see the difference, time running 100,000 async calls. ;)
amazing presentation
6:12 "These are going to be really boring programs, but they're going to use concurrency to make the boring a little less interesting." :D
Can I please get the code snippets and slides for this?
Great!
It is out on vimeo now
08:40 Goroutines
10:29 Channels
Why his slides can run code😮 how did he do that?
WoW Moment at 28:16!!
great presentation.
Could someone explain through the Daisy Chain example at 26:27? Thanks!
The main idea is about creating 10000 blocked goroutines, each copies value from the right channel to the left channel. The creation sequence is from the last channel(leftmost) to the first one(rightmost). In each creation procedure, after finished creating the goroutine, the left channel is no longer needed, and the right channel becomes the left channel we will need in the next iteration, so we made the right become the left for next iteration during which a new right will be freshly made. After the creation completes, all 10000 goroutine are blocked, since no value is sent through the first(rightmost) channel. Then we sent a value, and the value get passed through all the channels and goroutines. The key point is that the whole procedure is really fast with go considering the total numbers of the goroutines. So goroutine is realy light-weighted.
Hi from 2024!
I met some difficulties in understanding of this code part, so I decided to rewrite one a little bit and add comments for better understanding. Here it its:
func main() {
n := 100000
// In Rob's code `right` variable has been initialized as `right := leftmost`
// However, it rewrites every time in for-loop below, so we don't have to initialize `right` here (what a pan!)
// But we have to keep visibility of this variable within the main function because we have to call it after for-loop
// The clearest way for us is to declare `right` variable here without initialization
var right chan int
leftmost := make(chan int)
left := leftmost
// I spent a lot of time to get the one simple point
// We're building a chains here from left to right
// Not from right to left as you can see in the picture with Gophers
// Don't be fooled by arrows direction
for i := 0; i < n; i++ {
right = make(chan int)
go f(left, right)
left = right
}
// I rewrite this code a little bit
// It's clearer for me than the Rob's code
// Just put a 0 to the rightmost channel to start the whole process
go func() {
right
34:55 Claps!!
where is boring func in FanIn program,give me a clear program to understand.pls tis a wonderful in golang
Nice
FYI: The example here ruclips.net/video/f6kdp27TYZs/видео.html does not work, runs forever. Had to refactor to use this: timeChannel := time.After(1 * time.Second). Go version: 1.14
Or a local problem time.After(900 * time.Millisecond), works
Looks cool, but I still don't get it - how are channels all that much different from threading ? What's the advantage over threads?
+Alex George tleyden.github.io/blog/2014/10/30/goroutines-vs-threads/
Alex George All concurrency implementation problems arise from threads accessing shared memory at the same time. Go takes a different approach by passing around memory to channels therefore providing implicit locking in a sense.
Goroutines are lighter than threads.
This video confused the hell out of me. So many assumptions and skipping steps. I’m left with at least an order of magnitude more questions than when I came in.
The slides link
talks.golang.org/2012/concurrency.slide#1
So, where's the code?
21:21 :: recieved ? from c2
good
waitForIt = make(chan bool) Shared between all messages(struct), so all goroutines will wait for bool message from "waiForIt chan" after finishing its own tasks. Then if the main function sends a bool to the shared "waiForIt" channel, which goroutine will get the bool first? it still could keep the sequence in order?
This reminds me of fork() and exec() calls to UNIX.
erlang without erlang
I think you better do what you have all the characteristics of all programming languages only it is activated and enable des modes
because by eliminating pointer index it increases security but loses dynamic processes ingenious little suspect. better have all the features including haskel but the default is to show and recommend, is concerned activate other types of programming to be even more popular and more free ... !!!
+babu OO creo que lo mejor es hacer lo que tenga todas las características de todos los lenguajes de programación solo que se activa y se des activa las modalidades
porque al eliminar los el indice de puntero aumenta la seguridad pero pierde dinamismo de procesos ingeniosos poco sospechados. mejor que tenga todas la características incluyendo haskel pero el por defecto es la que muestran y recomiendan, es cuestión activar las otras modalidades de programacion para que sea mas popular todavia y mas libre...!!!
Not sure did watch it yet.
The Talk is posted (after a year)
blog.golang.org/2013/01/concurrency-is-not-parallelism.html
Where can I find the ppt of it?
我是搞Java的英语贼差竟然能听懂，哈哈哈
Here's the URL: rspace googlecode com/hg/slide/concur.html#title-slide
ur url is broked dood
到此一游
looks like .net async
this is a c++ modified
its more like c modified.
Andrei Chikatilo?
Try Go
// You can edit this code!
// Click here and start typing.
package main
import "fmt"
func main() {
fmt.Println("Hello, world")
}
Same shit in Python : print 'Hello, world'
yeah thanks ill stick with python
Now try doing the channels example in Python
+koda kitty most of them would be trivial to do with asyncio
If you are judging a whole language based on hello world you are a idiot.
also have fun with GIL
So boring...
is Go mostly dead now?
Nope, its still super popular. And its popularity is still going up. It jumped from 54th to 13th in a year on the TIOBE index
lol, every single startup that you can find anywhere in europe and us are using go if not node.js . It's really popular for backend related tasks & systems programming. Because it's simple to read yet has all the tools to express something really complex.
Sorry, but C# and Java are better
Go is a lot faster. By a very large margin.
Go is a lower level language which actually requires you to know programming, if you want to do stuff.
C# and Java is high level programming which compiles as ugly buggy crap.
saying c# and java compile into "buggy crap" is pretty ignorant. You would be hard pressed to find an issue caused by compiling in c# or java. The issue most people have is with the garbage collection (go is also garbage collected by the way) being slow and the fact that memory management is mostly abstracted away.
As always though, a language is just a tool, and no one tool is universally the best. There are use cases where using c# (mainly for the .net stuff) or java is better than using go.
[___ ] compare code generated by go and by Java. if you don't believe me, look what Linus Tordsvalds says.
There is the perfect language. And its name is Haskell. This language has an almost human AI and it writes code by itself. But the Dark Government is trying hard to keep this language in secret.