so we start with 1- coarse Locks, and then to 2- finer locks, and then to 3- enough precise memory access patterns which doesn't require locking (since there is no sharing memory) Great Job Kantan, I really enjoy your videos in golang !!
Bruh, I have a Go interview tomorrow, just finished your Master Go Programming With These Concurrency Patterns video, and watching this now. A big thank you for this content.
Respect. Every piece of content I've watched from you is flawless. Your drawings and explanations are spot on. Thanks a lot for taking the time to share your knowledge.
Thank you! It’s always reassuring to see people actually appreciate the amount of effort I put in. Sometimes I feel like people only want to see overly simplified gimmicky content 🫠
Excelent video. For me confinment it was easy to understand because I already knew how an array/slice is stored in memory. Never tought about this pattern, and it is really cool and an elegant solution.
This is one of the best golang concurrency explanation, thanks for sharing Sir Anyway is there any group of Golang community that I can join to keep improving my golang knowledge?
Nice explaintion , Commenting for better reach Got the new way to handle the Datastructure and also learnt we have to always very cautious what we are writing
Hey your videos are really good ❤ Can you make one video on "learn go programming by contributing to open source" You can too suggest some best open source golang projects out there to contribute Would love to see this Thanks ✌️
Hmm, I don’t really know what the video would consist of. I mean of course, the more you contribute to open source, the better you will become.. but I don’t really have anything specific to say other than, just keep contributing to open source. Also, literally any open source project is fine imo. Thank you for the suggestion! 😊 If you have additional details please let me know!
Thank you. Nice. Just a remark: there are no shared resources in you example for confinement pattern. When shared resourced do exist, the confinement pattern is more complicated and involves channels.
Early gang lets go!!!! I get it, basically each goroutine is only going to changing a value at a particular address in memory. It has no idea about the array it is changing.
Aren’t slices, maps and channels passed by “reference” in func arguments? In that case, I believe that just passing the variable result as argument without its reference will lead to the same results.
So slices are a bit confusing but let me try to explain. In Go, slices are passed by value but a slice value is a header describing a section of a backing array. So if we just pass result in instead of a pointer to result, processData will basically just receive it’s own copy of a header to the same backing array. And when we append to that slice in processData, it will only modify the slice or header in the scope of processData. Since the slice in main() is a different slice.. it won’t get modified. Therefore, in each go routine, it will have its own slice… and append the processed data to it… then once that go routine finishes.. the processed data in the slice within the scope of that go routines processData call will be removed from the stack. So the end result is that the result slice in main() will be empty since each go routine was appending to its own slice. You can actually test this behavior quite easily. Just try it the way you mentioned and print the result both inside of processData and in main and you’ll see what I mean 👍
@@kantancoding Indeed, under the hoods things can get overly complicated, but you managed to summarize the whole concept. I’ve just re-watched your video on mastering concurrency patterns and I few this time I had a deeper understanding about your explanations. It’s a shame we can’t give more than one thumbs up to your videos.
You’ve actually inspired me to make a video explaining arrays & slices in Go so thank you! ❤️ Also, I’m happy that you were able to understand things more deeply. Thank you for your support. It really means a lot to me 😊
This is cool, thanks for the explanation. as a beginner in Go, is there a limit how many goroutines we can fork? I'm talking about large scale concurrency use case and wondering if we have to limit goroutines, or it doesn't matter as goroutines once they're done they get garbage collected, any details would be appreciated please, also feel free to provide any kind of resources related to this to read/watch
Hey! Thanks for watching. I’d say you are limited by the host system at the very least. The degree of such a limit would likely depend on the system or machine that it’s running on. Regarding other resources, if you are focused specifically on concurrency, this video is part of a playlist of 3 videos. I’d start with the concurrency patterns video 👍
Think of this series as a set of tools. I’m not saying that any one tool solves ALL problems. I’m presenting an array of tools (no pun intended) but in the real world, the specific project will determine which tools are viable in a given scenario.
Become a Golang Expert With This Hands-On Golang Course 👉 kantancoding.io
so we start with 1- coarse Locks, and then to 2- finer locks, and then to 3- enough precise memory access patterns which doesn't require locking (since there is no sharing memory)
Great Job Kantan, I really enjoy your videos in golang !!
Thank you! I really appreciate your support and I’m glad that the videos are helpful 😊❤️
Thanks for doing such great help to community .
It's a request to you please don't stop posting this type of valuable content for us.
Hi! Thank you for your support. New concurrency video coming soon 😊
Bruh, I have a Go interview tomorrow, just finished your Master Go Programming With These Concurrency Patterns video, and watching this now. A big thank you for this content.
No problem brother! Good luck with your interview 🚀
hey how did it go?
how did it go?
did it go?
Unfortunately He's fail his interview
really hight quality content. Thanks man.
Thank you for watching brother! I appreciate the support.
Respect. Every piece of content I've watched from you is flawless.
Your drawings and explanations are spot on. Thanks a lot for taking the time to share your knowledge.
Thank you! It’s always reassuring to see people actually appreciate the amount of effort I put in. Sometimes I feel like people only want to see overly simplified gimmicky content 🫠
The quality of this content is amazing, well done!
Much appreciated! I’m glad you enjoy it 😊
Excelent video. For me confinment it was easy to understand because I already knew how an array/slice is stored in memory. Never tought about this pattern, and it is really cool and an elegant solution.
Thank you! I’m glad it was interesting for you as well 🙂
Great content, thank you!
Nice Video and Loved your explanation.
Thank you for sharing
No problem! Happy to help 😊
This is one of the best golang concurrency explanation, thanks for sharing Sir
Anyway is there any group of Golang community that I can join to keep improving my golang knowledge?
Nice explaintion , Commenting for better reach
Got the new way to handle the Datastructure and also learnt we have to always very cautious what we are writing
Commenting really helps so thank you!! ❤️
Hey your videos are really good ❤
Can you make one video on "learn go programming by contributing to open source"
You can too suggest some best open source golang projects out there to contribute
Would love to see this
Thanks ✌️
Hmm, I don’t really know what the video would consist of. I mean of course, the more you contribute to open source, the better you will become.. but I don’t really have anything specific to say other than, just keep contributing to open source.
Also, literally any open source project is fine imo.
Thank you for the suggestion! 😊
If you have additional details please let me know!
Thank you. Nice. Just a remark: there are no shared resources in you example for confinement pattern. When shared resourced do exist, the confinement pattern is more complicated and involves channels.
🤔
Early gang lets go!!!!
I get it, basically each goroutine is only going to changing a value at a particular address in memory. It has no idea about the array it is changing.
Yes! I hope it helped! 😊
Thank you for your channel
Excellent resource
Gifted teacher
Thank you! I’m glad it helps 😊
Aren’t slices, maps and channels passed by “reference” in func arguments? In that case, I believe that just passing the variable result as argument without its reference will lead to the same results.
So slices are a bit confusing but let me try to explain. In Go, slices are passed by value but a slice value is a header describing a section of a backing array.
So if we just pass result in instead of a pointer to result, processData will basically just receive it’s own copy of a header to the same backing array.
And when we append to that slice in processData, it will only modify the slice or header in the scope of processData. Since the slice in main() is a different slice.. it won’t get modified.
Therefore, in each go routine, it will have its own slice… and append the processed data to it… then once that go routine finishes.. the processed data in the slice within the scope of that go routines processData call will be removed from the stack.
So the end result is that the result slice in main() will be empty since each go routine was appending to its own slice.
You can actually test this behavior quite easily. Just try it the way you mentioned and print the result both inside of processData and in main and you’ll see what I mean 👍
@@kantancoding Indeed, under the hoods things can get overly complicated, but you managed to summarize the whole concept. I’ve just re-watched your video on mastering concurrency patterns and I few this time I had a deeper understanding about your explanations. It’s a shame we can’t give more than one thumbs up to your videos.
You’ve actually inspired me to make a video explaining arrays & slices in Go so thank you! ❤️
Also, I’m happy that you were able to understand things more deeply. Thank you for your support. It really means a lot to me 😊
@@kantancoding Can’t wait to watch it!
So helpful
You're a never disappointing life saver!
I’m glad it was helpful! 😊
God bless you for this video bro.
I’m happy to help brother ❤️
Excellent explaination. Thank you!
Happy to help brother!
Thank you, your videos and content are great 💯😃👍
Happy to help 😊 and thank you!
This is cool, thanks for the explanation. as a beginner in Go, is there a limit how many goroutines we can fork? I'm talking about large scale concurrency use case and wondering if we have to limit goroutines, or it doesn't matter as goroutines once they're done they get garbage collected, any details would be appreciated please, also feel free to provide any kind of resources related to this to read/watch
Hey! Thanks for watching. I’d say you are limited by the host system at the very least. The degree of such a limit would likely depend on the system or machine that it’s running on.
Regarding other resources, if you are focused specifically on concurrency, this video is part of a playlist of 3 videos. I’d start with the concurrency patterns video 👍
Thanks@@kantancodingI watched part2 just now lol and I left one question, I'll look for part 3 for sure 😄Godo stuff
@@webcodeuniversity You watches part 2/2. There is a part 1/2 in the playlist.
Excellent
You've eliminated access to shared state. That's easy to do with arrays. What other data structures will this pattern work with?
Think of this series as a set of tools. I’m not saying that any one tool solves ALL problems. I’m presenting an array of tools (no pun intended) but in the real world, the specific project will determine which tools are viable in a given scenario.
Which Fonts?
Yeahh.... Thank you kantan❤❤
My pleasure 😊
What is the name of vscode theme you used?
Most likely Dracula
excellent content
Thank you! ❤️
would it work if result is []char ? Coming from the C world😊 where concurrent writes to addresses that are in the same 'word' would be unsafe
Hey sorry, haven’t watched this video in a while. Would what work?
So Mutex is like Python's GIL or like Thread.lock?
I’m pretty sure the GIL is a mutex but you should confirm. As for Thread.lock, I’ve actually never used it so I don’t know. Thanks for watching! 😊
❤❤❤
Thansk a lot You're amazing
Happy to help! Thanks for watching 🥹