channel concept is quite hard to get used to, but once get used to it, it is really awesome! and now I learn more about channel, it feels always learning new thing ;( I doubt I can say I know channel at all... maybe this time...!
One little clarification. Around 6:24 he says that ok will be true/false if the channel is open or closed. It stays true if the channel is closed and still has values to consume. Here's a useless example, where the channel is filled to 2/3's capacity, then closed before we ever begin reading, but it can read all the values that were present when checking "ok" play.golang.org/p/8Q8zR1o5Mjz
I was interested in how you merge a variable number of channels in the "merge" function. It turns out you could solve this by using "reflect.SelectCase" and then replace the "select" statement with "reflect.Select" - maybe less efficient than when you know the number of channels beforehand, but useful where you want to add/remove channels whilst your program is running.
I'm not convinced it's a terrible approach but as Nic says, worth benchmarking. The other way of doing this I can think of is to fire off a go routine for every new channel you add and want to merge. Go routine ends when the incoming channel is closed, I guess?
Hey, I've always wondered how is dependency injection handled in Go. Can you talk about that next or point me to other material? I've only used Java (So.. Spring/Guice and some other obscure library) which make things "simple" with annotations, but how does this work in Go? I guess it's not that comparable to Java because there are no things like classes, but on a large system how are objects created and passed around?
+JustForFunc, I'm just trying to figure out if Go has anything like Guice for Java or how should I be thinking about that. Joe Carter talked about github.com/facebookgo/inject which is close to what I'm looking for
Does anybody know the rationale behind the decision to always return a pair of zero and false from a closed chan? Is it to recognize closed channels or are there other use cases?
false allows you to recognize a channel is closed vs someone sent a 0 through the channel the fact that the zero is returned it's because it needs to return something, and the zero value for ints is zero if your channel was of bools it would return false, false if it was pointers it would be nil, false etc
Reading from a infinite blocking channel _outside_ of a select{}-Statement would cause the reading goroutine to stop working, since there is no timeout for a read from a chan. This would also be the case, when _all_ channels used in a select{}-Statement are closed&blocking. By assigning nil to a chan, you're basically saying "Yes, I know that this will block forever and can therefor be dangerous, but I know what I am doing: there still is another chan I intend to read from in the selectt{}-Statement"
Very nice channel! I am currently learning go so that I can work on a repo I am following closely. github.com/lightningnetwork/lnd I would love if you could find something in there that you think is an interesting use of golang, or something you don’t like (and could be a good start of a pull request for golang beginners) for this repository.
I love this format, short but teaches a valuable lesson.
The background music at 11:24, and all the facial and body gesture from Francesc is so cute.
That is incredibly informative. Thank you!
channel concept is quite hard to get used to, but once get used to it, it is really awesome!
and now I learn more about channel, it feels always learning new thing ;( I doubt I can say I know channel at all... maybe this time...!
Great episode, really enjoyed the tips I learned from this short but very useful lesson
this is just perfect, thank you!
I demand more tutorials like this!
this is actually really great video! Good job man :D!
Loved this episode. Please share more neat tricks with us.
One little clarification. Around 6:24 he says that ok will be true/false if the channel is open or closed. It stays true if the channel is closed and still has values to consume. Here's a useless example, where the channel is filled to 2/3's capacity, then closed before we ever begin reading, but it can read all the values that were present when checking "ok" play.golang.org/p/8Q8zR1o5Mjz
It's false only once there's no more values in the channel and it has been closed already.
I was interested in how you merge a variable number of channels in the "merge" function. It turns out you could solve this by using "reflect.SelectCase" and then replace the "select" statement with "reflect.Select" - maybe less efficient than when you know the number of channels beforehand, but useful where you want to add/remove channels whilst your program is running.
Benchmark reflect.Select before you do that to your code.
reflect: no no no no no no no
there's much better ways of doing this ... and I've added this idea to my episode list!
I'm not convinced it's a terrible approach but as Nic says, worth benchmarking. The other way of doing this I can think of is to fire off a go routine for every new channel you add and want to merge. Go routine ends when the incoming channel is closed, I guess?
@Fransesc Could you please link to the episode about the Runtime Tracer that you mentioned at #8:32 in the video description?
Found it: ruclips.net/video/ySy3sR1LFCQ/видео.html
Greate video! Love the short format. More code reviews please!
Awesome, very valuable as always, thank you for the excellent episode.
Thanks for sharing this. It is very helpful.
Learned something new today. Thanks Francesc! 👍
Fransec for president
Francesc ... and no thanks, I'm good. Really 😅
@@JustForFunc if you were working in the field of InfoSec, FranSec would be a pretty badass company name for you
Very nice, short and informative.
Awesome as usual! What's that epic audio towards the end, around 11:23? :)
super mario:)
+Michael Hausenblas it's a secret! but I'm sure most people recognize
I see lots of post about using channels and goroutines to create pipelines but nobody ever talks about testing such pipelines
This was so simple and useful! Kudos!
I enjoyed this episode. It was short and well explained.
Hey, I've always wondered how is dependency injection handled in Go. Can you talk about that next or point me to other material?
I've only used Java (So.. Spring/Guice and some other obscure library) which make things "simple" with annotations, but how does this work in Go?
I guess it's not that comparable to Java because there are no things like classes, but on a large system how are objects created and passed around?
+Goodwine Carlos what are you trying to solve with dependency injection exactly?
Facebook have a nice little dependency injection library on github I've used before. It's a little rough around the edges but it works.
+JustForFunc, I'm just trying to figure out if Go has anything like Guice for Java or how should I be thinking about that. Joe Carter talked about github.com/facebookgo/inject which is close to what I'm looking for
Stop thinking in terms of java when dealing with Go!
Thanks, great format!
what happens if the caller tries to recveive from the channel once its set to nil?
Blocks forever
Thanks for explaining nil channel use case 😀
you took it from "100 mistakes and how to avoid them book", right? :)
Does anybody know the rationale behind the decision to always return a pair of zero and false from a closed chan? Is it to recognize closed channels or are there other use cases?
false allows you to recognize a channel is closed vs someone sent a 0 through the channel
the fact that the zero is returned it's because it needs to return something, and the zero value for ints is zero
if your channel was of bools it would return false, false
if it was pointers it would be nil, false
etc
Thanks! The more I learn about go, the more I value its design.
Why "it needs to return something" after all? Why can't Go just makes it block the select case similar as nil channel once a channel is closed?
Reading from a infinite blocking channel _outside_ of a select{}-Statement would cause the reading goroutine to stop working, since there is no timeout for a read from a chan. This would also be the case, when _all_ channels used in a select{}-Statement are closed&blocking. By assigning nil to a chan, you're basically saying "Yes, I know that this will block forever and can therefor be dangerous, but I know what I am doing: there still is another chan I intend to read from in the selectt{}-Statement"
Read more about these kind of patterns here: nomad.uk.net/articles/interesting-ways-of-using-go-channels.html
Owww yeah, a new just for func video!
Great episode!
Thanks for the func!
THANK YOU
THANK YOU
THANK YOU !!!!!!!!!!!!
Thanks! I like this non nil channel ;)
great video
Good Job! Started yesterday, Now I think I'm getting addicted to the channel. xd.
👍👍👍👍👍
🎶 👍 👍 🎶
Fucking awesome!
Mind = blown
awesome
wow
Very nice channel!
I am currently learning go so that I can work on a repo I am following closely.
github.com/lightningnetwork/lnd
I would love if you could find something in there that you think is an interesting use of golang, or something you don’t like (and could be a good start of a pull request for golang beginners) for this repository.