The difference is which option they encourage, and which option requires an explicit choice.
But it takes a couple strange turns when it suggests that (a) you should ALWAYS use sync primitives, and (b) waitgroups/nurseries are the only sync primitive worth using.
If I'm only spawning off one parallel thread, a simple join statement is all I need. If I'm doing an async task, a promise is plenty.
If there's a true fork in my execution, maybe I don't want to use a sync primitive at all. Go cleans up stray goroutines on process termination, so if my program's logic doesn't demand that my goroutines join back together, why should they? Let them terminate themselves, or let them live forever.
There are more concurrency models in heaven and earth than are dreamt of in this guy's philosophy. It's not that I think waitgroups are a bad primitive or anything, I just think it's a bit much to take a useful primitive and go "this should be the only tool that is ever used to manage concurrency."
https://golang.org/pkg/#subrepo
> These packages are part of the Go Project but outside the main Go tree. They are developed under looser compatibility requirements than the Go core.
(Also, SEGVs are well behaved enough to implement userspace virtual memory on top of, if that's your fetish... not sure what the spec says, but it's not UB in actual practice. Trying to resume from an assert() is indeed UB though since that'd be returning from a noreturn function.)
Did this change at some point?
This is an example I made. Can you show how that would change to cause the problem you're describing?
Also, see the Go spec: https://golang.org/ref/spec#Handling_panics
> Next, any deferred functions run by F's caller are run, and so on up to any deferred by the top-level function in the executing goroutine. At that point, the program is terminated and the error condition is reported, including the value of the argument to panic.
It looks like, assuming it makes it to the top of the current goroutine, then it should be killing the whole program.
Personally I don't use panics or deal in them that much, mainly because stack traces with multiple goroutines are unbelievable. I much prefer errors.
Still, that made it less flaky for a bit, but the it printed again! And I realized what else is going on: There's actually time between when the deferred functions are executed and the program exits! Which is fascinating, but unlikely to matter in practice. It brings me to another question: do deferred statements still get called when there's a panic on a different goroutine? And the answer seems to be no; adding a deferred print to the main function does not print.
I think intuitively I probably knew that a panic in a goroutine will shut down the main thread, it just didn't occur logically to me when I read it; which is an interesting paradox. Maybe that's a me-thing though.
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 nursery is restrictive which has its benefits, but I don't agree that it's just strictly always the preferred approach. I prefer an approach like Go's, where you can choose whether to use nurseries (errgroups), and the implementation for them is provided by the language authors. Sure, you are able to start and manage goroutines in this way, even if you don't care about their lifetime - as they are effectively individual programs, but you shouldn't HAVE to.
So when you care about goroutines running only while their starter goroutine is at a certain scope, you can do so. But you don't have to, and when you don't need it - you don't need to pay the price. Go appears to take an approach that provides primitives that are as least restrictive as possible to make it easy to read code, but then also has a batteries included approach with its libraries.