var wg = sync.WaitGroup
defer wg.wait()
wg.Add(1)
go func() {
defer wg.Done()
}
)And create a separate channel to return errors from a goroutine. Definitely more work.
var wg = sync.WaitGroup
defer wg.wait()
wg.Add(1)
go func() {
defer wg.Done()
}
)And create a separate channel to return errors from a goroutine. Definitely more work.
Also I don't understand "it's not trivial to grow them". It is trivial to grow them, and that's why Go went this way. Maybe only 0.1% or fewer of use-cases will ever find any issues with the resizing stack (in fact probably the majority of uses are fine within the default starting stack size).
Well, guess how coroutines are implemented in Rust/C++/everywhere else!
Nonetheless, I do think that java virtual threads are superior for the vast majority of use cases and they are a good default to reach for for "async" like code.
No, you don’t. Any stack-allocated resources are freed when the function returns. WaitGroup is just there for synchronization.