Wrote the goroutine leak while building a small custom cron scheduler.
The leak is well-documented, and Uber included it as one of the most . I have debugged it multiple times before in prod, but this kinda shows how easy it is to write bugs like this, even when you're aware.
Found it while playing with . I like the fact that now I don’t have to use goleak and write tests to ensure they exercise the leak path and raise flags. But it seems like a patch rather than tackling the issue head-on.
Go concurrency often feels a bit too low-level, and at our scale, we have felt the need for some structured concurrency paradigms.
Sure, with waitgroups and errgroups you can roll your own, but languages like Python and Kotlin have scoped suspension where you do something in a block and then cancel the whole block if something fails. It's possible to do it in Go, but requires quite a bit of boilerplate and is hard to teach. Folks new to the language write some haunting concurrency bugs and leaks due to the lack of this. At least we can catch most of them now.
IIRC, there was a conversation around structured concurrency a few years back, but I guess no consensus was reached. Peter Bourgon's Run tried to bring actors but hasn't gained as much traction, I guess.
Is anyone using anything beyond handrolled waitgroups?
