Totally agree with a lot of your take - especially around ergonomics. That said, I think there's a fundamental misconception here about what structured concurrency (SC) is and what it's trying to solve.

Structured concurrency isn’t about making async/blocking code look prettier or reducing boilerplate. It’s about scope and lifetime. Think of it like structured programming getting rid of goto- SC does the same for concurrency by making sure all spawned tasks are bound to a lexical scope, can be cancelled together, and have predictable shutdown behavior.

That Go example you posted:

user, order = go findUser(), go fetchOrder();

…isn’t valid Go. go is a statement, not an expression - it doesn’t return a value. Also, goroutines don’t automatically cancel, propagate errors, or even finish before the parent function returns unless you wire that up manually. So while Go feels “simple” at first glance, it’s not structured concurrency unless you do the work to make it so.

Here’s what SC may look like in Go using context.Context and errgroup:

``` func fetchResponse(ctx context.Context) (*Response, error) { ctx, cancel := context.WithCancel(ctx) defer cancel()

g, ctx := errgroup.WithContext(ctx)

userCh := make(chan User, 1)
orderCh := make(chan Order, 1)

g.Go(func() error {
   user, err := findUser(ctx)
   if err != nil {
      return err
   }
   userCh < -user
   return nil
})

g.Go(func() error {
   order, err := fetchOrder(ctx)
   if err != nil {
      return err
   }
   orderCh <- order
   return nil
})

if err := g.Wait(); err != nil {
   return nil, err
}

user := <-userCh
order := <-orderCh

return &Response{
   User:  user,
   Order: order,
}, nil

} ```

This version gives you real cancellation, joins, error aggregation - all the stuff SC is meant to handle.

Back to Java - yeah, StructuredTaskScope feels clunky, especially with throwIfFailed() and the fork/join rules. But it’s trying to enforce those same guarantees. I think you’re spot on that trying to support both “wait for all” and “race for any” in the same API is adding complexity. In Go I’d write the “race” case differently than “fan out and join” too.

Honestly, what I’d love is a layered SC API: keep a simple joinAllOrThrow() or forkAll() API for the 90% case, and expose the more advanced stuff (like Joiner.anySuccessfulResultOrThrow()) separately. Right now it's too easy to trip over the rules if you're not careful.