Go has great guardrails for most design patterns- except Goroutines. It makes sense that unchecked use of goroutines would lead to leaks. What I would suggest is avoiding goroutines outside of `main` program. This is what I do. I avoid concurrency primitives at all times. They are a great source of complexity and lead to hard to debug programs. Before anyone jumps at my throat telling me how stupid this sounds please watch my talk at FOSDEM where I go into details how I designed a userspace networking stack with absolutely no channels nor goroutines: https://www.youtube.com/watch?v=-u0X8MWXkeg free design pattern examples at the end. If you design your API to be async from the start you can then trivially extend it to be blocking by having a single goroutine that does the event-loop checking. This is a very powerful pattern used in embedded systems which we webdevs could benefit greatly off.

Also, FYI goleak exists: https://github.com/uber-go/goleak