Notes on structured concurrency, or: Go statement considered harmful

What. This article proposes a "nursery", which is just a wrapped sync.WaitGroup/pthread_join/futures::future::join_all/a reactor that waits for all tasks to terminate/etc. It then uses an exception-like model for error propagation to "solve" error handling (which is fairly easy to handle with a channel). The construct is a decently usable, already applied tool to handle a set of problems, but the article takes the issue way out of proportions and overhypes the proprosed solution. The "with" example for benefits to…

There's one key difference between Go and all the other examples: an uncaught panic in any goroutine, not just the main goroutine, crashes the app. Often your main goroutine will just be starting other goroutines, in a multiple-services-one-process architecture, and it doesn't care whether they succeed or not, and its code need not be aware of whether they're critical. If they are, they should panic and crash the program. Just like a main function that crashes. Doing things with the…

Can the discussions here try to stay away from Go bashing. This post is not about Go. It's about Structured concurrency VS background tasks. There's many interesting discussions one can have about the latter but the former turns into toxicity. With that said. The Rust teams are very interestes in structured concurrency at the moment. Rust 1.63 is going to get scoped threads, which is structured concurrency for threading. Myself and others have also been looking into structured async, albeit…

Seven years later, and the sort of fan out/in behavior proposed here is implemented all the time where necessary but not considered a concurrency primitive. I think I remain more interested in the erlang/elixir process approach to concurrency. Practically that seems so much more powerful than anything else available today.