► Join my Discord community for free education 👉 discord.com/invite/Ac7CWREe58 ► Exclusive Lessons, Mentorship, And Videos 👉 www.patreon.com/anthonygg_ ► 60% BLACK FRIDAY DISCOUNT on my Golang course 👉 fulltimegodev.com Thanks for watching
you can build your own waitGroup with go routine and channels, its just an abstraction you can either use it if it perfectly fits your needs or build one that does
pls make a video about fan-in, fan-out patterns and usage of select keyword when working with multiple channels (also would be great if buffers, read and write chanells would be also discussed). My appreciation, maestro!
I think you could skip the wg in the last example by using just an int that is decremented inside the for loop and making the loop sync inside the main. When the last value is received and the counter is zero, just close the channel and the execution of the main function continues
ปีที่แล้ว +1
Amazing video! I learned to add the waiter and the close into an anonymous go routine and keep the code out of the anonymous go routine. Thanks for this rich material
I think the reason why it didn't execute the last print is that the block that executes the channels' print is in a separate go routine, and the main function is also a go routine meaning that it's not included on the WaitGroup, such that once the WaitGroup is done on the main go routine it already exited the function hence the print inside the go routine is not included on the WaitGroup and is executed after the main go routine has done its task.
I've solved the problem in video by creation of second Waitgroup for processing results and closing channel after all workers are done - e.g. after wg.Wait() exists, now it works flawlessly (noob in Go, so I believe there are something like simple mutex instead of Workgroup for awaiting results processed in Go, but I know nothing yet about it): wgProcess := sync.WaitGroup{} wgProcess.Add(1) wg = &sync.WaitGroup{} wg.Add(3) go dowork(2*time.Second, ch) go dowork(4*time.Second, ch) go dowork(6*time.Second, ch) go func() { for r := range ch { fmt.Println(r) } fmt.Printf("Work done in %v ", time.Since(start)) wgProcess.Done() }() wg.Wait() close(ch) wgProcess.Wait() fmt.Println("Exited")
GG video man. When I was learning golang the when to use go routines with channels was a bit hard to understand and I wish your video was out back then! Cheers mate good job
When you demonstrated channels, I think you can make(chan string, size) so you can mimick the config you had with waitgroups. You'll only be expecting 3 messages into the channel and then close it.
You are describing a buffered channel, which is really different from a channel which your only expect 3 values. What the buffer does is to prevent the channel from blocking when giving it values up to the capacity.
Are there any disadvantages of using this approach? For example if we need to make multiple parallel requests to fetch different type of results. func main() { start := time.Now() var r1 string var r2 int var r3 time.Time wg := sync.WaitGroup{} wg.Add(3) go func(wg *sync.WaitGroup) { r1 = "Hello" time.Sleep(1 * time.Second) wg.Done() }(&wg) go func(wg *sync.WaitGroup) { r2 = 42 time.Sleep(2 * time.Second) wg.Done() }(&wg) go func(wg *sync.WaitGroup) { r3 = time.Now() time.Sleep(3 * time.Second) wg.Done() }(&wg) wg.Wait() fmt.Println(r1, r2, r3) fmt.Printf("took: %v ", time.Since(start)) }
Would it make sense to invert your example, pass the wg.Wait to your anonymous function and have the channel for on the main thread to get results back to main thread? I suppose you could also pass a slice to the function instead of the wg
I don't use channels unless something is asynchronous forever. I just sense I'm wasting code harvesting channel results, when mutexes allow for arbitrarily large expansions into accepted containers.
Is it really the compiler being smart or the runtime? Inhoni think has nothing to do with compiler if deadlocks detected. Anyway, I love your videos it's easy to understand. 🤷♂️
But it feels like using both channels with waitgroups are taking more resources. Didn't test myself but heard using channels is much efficient and preffered than wg. Any other approaches to control that job is done? contexts?
Thanks Anthony, just a quick question is it a possible to close the channel inside the go routine in this way go func() { for res := range resultch { fmt.Println(res) } fmt.println() close(resultch) }() if it is possible, is it considered a good practice?
► Join my Discord community for free education 👉 discord.com/invite/Ac7CWREe58
► Exclusive Lessons, Mentorship, And Videos 👉 www.patreon.com/anthonygg_
► 60% BLACK FRIDAY DISCOUNT on my Golang course 👉 fulltimegodev.com
Thanks for watching
TL;DR
Use waitgroups when you don't want goroutine to return some data.
Use channels when you do want goroutine to return some data.
you can build your own waitGroup with go routine and channels, its just an abstraction you can either use it if it perfectly fits your needs or build one that does
pls make a video about fan-in, fan-out patterns and usage of select keyword when working with multiple channels (also would be great if buffers, read and write chanells would be also discussed). My appreciation, maestro!
I think you could skip the wg in the last example by using just an int that is decremented inside the for loop and making the loop sync inside the main. When the last value is received and the counter is zero, just close the channel and the execution of the main function continues
Amazing video! I learned to add the waiter and the close into an anonymous go routine and keep the code out of the anonymous go routine.
Thanks for this rich material
I think the reason why it didn't execute the last print is that the block that executes the channels' print is in a separate go routine, and the main function is also a go routine meaning that it's not included on the WaitGroup, such that once the WaitGroup is done on the main go routine it already exited the function hence the print inside the go routine is not included on the WaitGroup and is executed after the main go routine has done its task.
I've solved the problem in video by creation of second Waitgroup for processing results and closing channel after all workers are done - e.g. after wg.Wait() exists, now it works flawlessly (noob in Go, so I believe there are something like simple mutex instead of Workgroup for awaiting results processed in Go, but I know nothing yet about it):
wgProcess := sync.WaitGroup{}
wgProcess.Add(1)
wg = &sync.WaitGroup{}
wg.Add(3)
go dowork(2*time.Second, ch)
go dowork(4*time.Second, ch)
go dowork(6*time.Second, ch)
go func() {
for r := range ch {
fmt.Println(r)
}
fmt.Printf("Work done in %v
", time.Since(start))
wgProcess.Done()
}()
wg.Wait()
close(ch)
wgProcess.Wait()
fmt.Println("Exited")
That's what I was thinking too, I agree
GG video man. When I was learning golang the when to use go routines with channels was a bit hard to understand and I wish your video was out back then! Cheers mate good job
in last example you can leave your channel iterating and else outside of goroutine, but spin up goroutine which basically waits and closes channel
Is there a way to do without a WG when you don't know how many routines will be there?
well you always know. you don’t have to add to waitgroup before everything. you can add to it when you about to spawn another goroutine
From now on I am calling my wait groups "weegee" :D
When you demonstrated channels, I think you can make(chan string, size) so you can mimick the config you had with waitgroups. You'll only be expecting 3 messages into the channel and then close it.
You are describing a buffered channel, which is really different from a channel which your only expect 3 values. What the buffer does is to prevent the channel from blocking when giving it values up to the capacity.
Best video on channels and waitgroups ❤
Great - really good simple demo - thanks
legend back
G.O.A.T as always ❤
Are there any disadvantages of using this approach? For example if we need to make multiple parallel requests to fetch different type of results.
func main() {
start := time.Now()
var r1 string
var r2 int
var r3 time.Time
wg := sync.WaitGroup{}
wg.Add(3)
go func(wg *sync.WaitGroup) {
r1 = "Hello"
time.Sleep(1 * time.Second)
wg.Done()
}(&wg)
go func(wg *sync.WaitGroup) {
r2 = 42
time.Sleep(2 * time.Second)
wg.Done()
}(&wg)
go func(wg *sync.WaitGroup) {
r3 = time.Now()
time.Sleep(3 * time.Second)
wg.Done()
}(&wg)
wg.Wait()
fmt.Println(r1, r2, r3)
fmt.Printf("took: %v
", time.Since(start))
}
Would it make sense to invert your example, pass the wg.Wait to your anonymous function and have the channel for on the main thread to get results back to main thread? I suppose you could also pass a slice to the function instead of the wg
Yes there are multiple solutions. I just came up with something straightforward and I hope easy to understand for people that are new.
What about the switch{} block and label brakes in for loop instead of using the waitgroups along with channels?
super clear and easy to understand thank u
Great class!!! Personally I learn a lot
I don't use channels unless something is asynchronous forever. I just sense I'm wasting code harvesting channel results, when mutexes allow for arbitrarily large expansions into accepted containers.
Volume becomes lower and lower with every next video, please make it at least a little bit louder, it's becoming hard to listen. Thanks for your work.
Ok I will investigate this sounds issue
Hmm, shouldn't it be better if we just defer the Chan closing instead of using sleep?
Is it really the compiler being smart or the runtime?
Inhoni think has nothing to do with compiler if deadlocks detected.
Anyway, I love your videos it's easy to understand.
🤷♂️
What's the color theme are you using?
Thanks
Probably Gruvbox
but we need the the result inside the main, adding the the for loop inside a goroutine then we can't have the results in the main
But it feels like using both channels with waitgroups are taking more resources. Didn't test myself but heard using channels is much efficient and preffered than wg. Any other approaches to control that job is done? contexts?
100% correct. Context is also a good option. There is a video on that also.
@@anthonygg_ will check it right nao
Why don't we add wg.Done in the local function instead of sleep
Thanks Anthony, just a quick question
is it a possible to close the channel inside the go routine in this way
go func() {
for res := range resultch {
fmt.Println(res)
}
fmt.println()
close(resultch)
}()
if it is possible, is it considered a good practice?
You are blocking on the for loop so closing wont be triggered
But at the end if you have more than 2 channels you always use wait groups? I dont understand
Im wondering why the wg.done() was not called? and without that how did the wg know that all goroutes are comeplted?
Audio is super low, had to max out my volume to hear
YOU ARE HIM
😹😹😹
You have 4 gorutines and 3 wait groups, and that's the reason it didn't want for last print, things happens, But Overall great video.
Great video, both well explained and helpful, thank you!
WEEEGEEE >>>>>>
Please make a video on different rate limiting patterns
If I apply to be a partner on the website, are there translation subtitles? thai😢
Nee maat gewoon assembly
🥲
2
1
Done decrement the number inside the wg.add