Thanks for explaining the loop variable "problem" so clearly - have read a lot about it, but your explaination illustrated the underlining Go runtime workings which caused the behaviour.
I've never go this "problem" cause I've always tought that every goroutine has its proper scope : [...] go func(vcopy string) { fmt.Println(vcopy) }(v) [...]
I mean, it's in every piece of documentation surrounding goroutines. This definitely isn't obscure. It's just like off-by-1 errors- devs just simply not paying attention.
I don't know if I'd call it Silly, I think it's an important aspect for Adoptability. We may call it DevExp if you like that more. Well, wouldn't you say Go already has great compability and consistency? So what's wrong with tending to the more junior developers? I don't see any harm in this improvement
Percy can you suggest me some books I wanna learn Networking stuff with Golang I am learning Golang from Orielly Cookbook the Network module was super interesting @@programmingpercy
Hey Percy can you please suggest some books for Networking stuff in Golang I was learning Golang from the Orielly Go Cookbook their Networking module was so fascinating Are there any books or docs in your mind apart from official.
Thank you for the videos! I'm also have been learning and programming in go for the past two years, do you have any books that you recommend the best for microservices? I was looking into DDD by Matthew Boyle and EDD by Michael Stack
Nice to hear you are using Go, sure is amazing! Regarding DDD I'd recommend Eric Evans book, though it is a handfull to take in. A slightly simpler version is Implementing Domain Driven Design by Vaughn Vernon. It's a bit slimmer and more Concrete.
I'm sorry but I'm trying to understand how is for loop + goroutine behavior a bug. What you are doing here is neither bad practice nor a freak behavior. It is behavior that is entirely expected from this code that is by all measures incorrectly written. THIS is the correct code that does exactly what you would expect: ``` names := []string{"Strale", "Caka", "Strahinja"} for _, v := range names { go func(name string) { fmt.Println(name) }(v) } ``` Example shown here (in the video) disregards basic concepts of multi threading that are surely covered on every computer science course on the planet. Now, I'm not trying to be rude and I very much apologize if that is the way I'm coming across. However, considering that there's no actual bug being presented here, how is this update a solution instead of an ability to allow programmers to write code that is, by every possible measure, bad?
I do understand your point and I do agree to some degree. It is doing what's expected. The problem is that there are too many developers that make the mistake, proven over and over. So many times that it's an apparent issue. You're not rude, you're just stating your opinion. I do try in the video to explain that it is expected behavior by showing what's actually happening. The issue is that it's to easy for many developers to not understand that. One might argue that's it's a unnecessary change because any decent Linter will prevent you from doing this mistake. But then we have reality, people don't use linters, people misunderstand things. The change won't harm anyone, but it will make it harder for people to screw up, so it's a win according to me. With the logic that people should just learn to understand, we wouldn't need a GC. If people just learn to free up mem and handle everything as they are suppose to, the GC is just pointless. Logic is sound, but reality is another beast.
@@programmingpercy You do make a good point. If majority makes a mistake than it makes more sense to create means to correct a mistake than to expect all those people to get better. Thanks for the explanation
Imho these adjustments in go weren't needed. E.g. the for loop adjustment is simply required or at least it seems due to the fact that the people don't actually know what there doing or how the language works. I'm fine with them but i would the core team to focus on something else
I'd argue the for improvement is much needed. Too many silly bugs. I know its simple to fix the for issue, but it is too simple for new goers to miss understand the old implementation and make mistakes. The Servemux changes aren't needed either, but they are a nice UX upgrade to the http lib. I welcome them! Also the changes on the slices package are pretty sweet. But sure, most of the changes were UX improvements to make it easier. I like easier.
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Love the way you summarize the new features! Thanks for the hard work
Good work! Thanks… Which tool did you use in this video for graphical schema?
That's a tool called Exalidraw and it's amazing.
You can easily selfhost it using Docker.
excalidraw.com
Thanks for explaining the loop variable "problem" so clearly - have read a lot about it, but your explaination illustrated the underlining Go runtime workings which caused the behaviour.
I've never go this "problem" cause I've always tought that every goroutine has its proper scope :
[...]
go func(vcopy string) {
fmt.Println(vcopy)
}(v)
[...]
Even thou you have a point, passing the current name as a parameter to the go routine function pretty much solves the issue
Agreed, although this is a very common mistake I've seen way too many times in code reviews. And out in the wild of running code.
I mean, it's in every piece of documentation surrounding goroutines. This definitely isn't obscure. It's just like off-by-1 errors- devs just simply not paying attention.
Sure it's well known, still often occuring.
And if it's happening a lot, then it's an UX issue.
Simple change that will help a ton developers.
@@programmingpercy "UX" for a language is silly. Consistency and capability of a language come MILES before attempting to babysit PEBKAC.
I don't know if I'd call it Silly, I think it's an important aspect for Adoptability.
We may call it DevExp if you like that more.
Well, wouldn't you say Go already has great compability and consistency? So what's wrong with tending to the more junior developers?
I don't see any harm in this improvement
Thanks for the examples.
Thank you!
Thank you for the video dude !! keep goin
Thanks, I intend too
The main reason I was using third party libraries for http was the dynamic paths. Now I don't need to.
I feel the same way!!
What about subrouters?
Great video, keep up the good work 😊👍
Thank you for watching and enjoying!
Amazing , Love your explanations !
Happy you enjoyed
Thanks Percy for sharing.
Thank you for watching!
Percy can you suggest me some books I wanna learn Networking stuff with Golang
I am learning Golang from Orielly Cookbook the Network module was super interesting
@@programmingpercy
Hey Percy can you please suggest some books for Networking stuff in Golang
I was learning Golang from the Orielly Go Cookbook their Networking module was so fascinating
Are there any books or docs in your mind apart from official.
for range on ints is pretty cool too!
for example, you can now write benchmarks as: for range b.N { ... }
Amazing! Didn't even think about that!
That is a nice improvement indeed!!
Ints or uints? How does it handle a negative integer as the range start?
@@brentsaner just tried it. The loop is not executed
Sir make a series and deep dive into net/http
Added to backlog.
Very good video, thanks 🎉
Thank you for watching! Makes it more fun to make these things when people watches it
Thank you for the videos! I'm also have been learning and programming in go for the past two years, do you have any books that you recommend the best for microservices? I was looking into DDD by Matthew Boyle and EDD by Michael Stack
Nice to hear you are using Go, sure is amazing!
Regarding DDD I'd recommend Eric Evans book, though it is a handfull to take in.
A slightly simpler version is Implementing Domain Driven Design by Vaughn Vernon. It's a bit slimmer and more Concrete.
I'm sorry but I'm trying to understand how is for loop + goroutine behavior a bug. What you are doing here is neither bad practice nor a freak behavior. It is behavior that is entirely expected from this code that is by all measures incorrectly written.
THIS is the correct code that does exactly what you would expect:
```
names := []string{"Strale", "Caka", "Strahinja"}
for _, v := range names {
go func(name string) {
fmt.Println(name)
}(v)
}
```
Example shown here (in the video) disregards basic concepts of multi threading that are surely covered on every computer science course on the planet.
Now, I'm not trying to be rude and I very much apologize if that is the way I'm coming across. However, considering that there's no actual bug being presented here, how is this update a solution instead of an ability to allow programmers to write code that is, by every possible measure, bad?
I do understand your point and I do agree to some degree.
It is doing what's expected.
The problem is that there are too many developers that make the mistake, proven over and over.
So many times that it's an apparent issue.
You're not rude, you're just stating your opinion.
I do try in the video to explain that it is expected behavior by showing what's actually happening.
The issue is that it's to easy for many developers to not understand that.
One might argue that's it's a unnecessary change because any decent Linter will prevent you from doing this mistake.
But then we have reality, people don't use linters, people misunderstand things.
The change won't harm anyone, but it will make it harder for people to screw up, so it's a win according to me.
With the logic that people should just learn to understand, we wouldn't need a GC. If people just learn to free up mem and handle everything as they are suppose to, the GC is just pointless. Logic is sound, but reality is another beast.
@@programmingpercy You do make a good point. If majority makes a mistake than it makes more sense to create means to correct a mistake than to expect all those people to get better. Thanks for the explanation
Imho these adjustments in go weren't needed. E.g. the for loop adjustment is simply required or at least it seems due to the fact that the people don't actually know what there doing or how the language works. I'm fine with them but i would the core team to focus on something else
I'd argue the for improvement is much needed. Too many silly bugs.
I know its simple to fix the for issue, but it is too simple for new goers to miss understand the old implementation and make mistakes.
The Servemux changes aren't needed either, but they are a nice UX upgrade to the http lib. I welcome them!
Also the changes on the slices package are pretty sweet.
But sure, most of the changes were UX improvements to make it easier.
I like easier.
100% agreed. They spent time on *this* and NOT ENUMS?!