I just started playing with Go last week. This morning, I wrote a chat server that uses a defacto pool of goroutines where each goroutine resets after the connection drops. I'm pretty stoked about it.
@@riteshgsh I found a bit later (after switching back to Python as my main language) that there were some bugs in it. I haven't yet figured out how the bugs are caused to fix them, so it's probably not the best example to reference.
Ryan, great channel! One of the better channels for experienced devs wanting to grasp Go concepts quickly but communicated well enough for beginners to use.
I love the diversity of content on this channel. I used to do game dev with Unity and I’ve been doing TypeScript for a while and now I’m getting into Go, so I relate a lot with your content 😂
Would it be fair to say that the reason this application is being killed at the 200MiB limit is more about what the Process() func is allocating, and not really about the goroutines? I agree that for this specific use case, limiting the # of concurrently running goroutines will implicitly limit the number of concurrent Process() allocations being made? Goroutines are exceptionally lightweight at a 2kb stack. Busy backends can use thousands of goroutines no problem. You conveyed limiting the number of go routines running for the Process() function wonderfully. Go's memory allocation can make it frustrating to deal with, and I've found the bounded channel approach you explained here to be an amazing way to control concurrent memory-hungry functions. Great content sir!
Hey Ryan! This video was awesome I have never seen something like this and you presented it in a way I just intuitively grasped. On question: what is that streaming / events package? Is it in the stdlib? I have an app right now at work that needs to stream data and throttle it and it’s kind of an ugly mess and I think I could clean it up a ton with that package and what you showed here.
Not sure if you are avoiding this because you don't want to get into it in the scope of this video but if you are passing a completely arbitrary value as a signal to a chan you almost always want to use type of struct{}. There's several good articles on why this is by Dave Cheney and others but essentially it uses no storage and is perfect for the use case in the video
Excellent video, thank you - I'm learning Golang and I am interested in using Golang with WebSockets rather than RabbitMQ (which I've had a play with) - so any vids on that topic would be of interest...
how you connected container with Go program, how the container showing memory usage when you run the Go program? can you make a detailed video on this one please
Ryan this is the only video from you that I've seen but I just wanted to tell you that your audio sounds like it's over-driven and distorted. I think if you would cut back on your mic gain by around 30% you would sound a lot better. Otherwise your content is great.
I encountered this disgusting 🤢 behavior in one of my app it occurred while topic lag processing, Go routine’s really can become ghost if you give them free hand
So Go doesn't have a concept of pool? That is a bit unfortunate as if you have many places in the codebase that use goroutines, managing this kind of limiting will be problematic.
7:00 well, the way you did it is not efficient at all. You want to limit the number of goroutines by 10, so you know that at the same time you won't have more than 10 workers, why don't you use worker pool pattern instead of semaphore, which in the video? More efficient way is to not spawn and kill goroutine, which has a little overhead, because we need to allocate and clean stack for each goroutine, but to keep them running as much as possible
Exactly. The author doesn't seem to know what he's doing. The overhead of goroutines makes it a bad idea to use them in such a disposable way when there are billions or trillions of events that need to be processed. He shows his bad pattern in multiple videos too. A worker pool would be more CPU efficient. Even with a worker pool, I check for system load to limit the number of active workers so as to prevent CPU contention.
@@vcool The cost of spawning a goroutine is pretty small, and not everyone is dealing with billions or trillions of events. Author did a great job showcasing a simple strategy to avoid OOM panics.
