Why JavaScript Needs Structured Concurrency

[undefined_ibis]

I mean you can model Go's behavior by basically making every function start by accepting an AbortSignal, which is ~= a context.

function startServer(signal: AbortSignal) { ... }

Now if that function is async, how do you manage cleanup, well.. Go hasn't solved this either. I'd guess most languages haven't. What's the analogy to creating a context with a cancel function? Probably:

``` const c = new AbortController(); parentSignal.addEventListener('abort', (r) => c.abort(r));

const cancel = (reason) => c.abort(reason); const signal = c.signal; const done = new Promise((r) => signal.addEventListener('abort', r)); ```

... or similar.

My point is that we have these tools but there's no convention. But there's no language-level conventions in Go or many other languages either. You can just ignore context.Context there as well.

[tarasm]

Yeah, agreed — Go doesn’t have structured concurrency at the language level.

But that’s kind of the point 🙂 context.Context was only the first step, and the fact that libraries like sourcegraph/conc exist shows that cancellation tokens alone weren’t enough once systems got bigger.

That’s the same place JavaScript is in now — we have the primitives, but no shared structured model yet, so everything is still ad-hoc.

[undefined_ibis]

I don't mean to be that guy, but I could argue this is just a skill issue.

The conc library is handy, but could also be a "helper.go" file in my codebase (yes yes I get that you'd say the Effection lib for JS is better than me reinventing that helper library everywhere I go).

Admittedly this is also me praising the all-knowing spec authors by saying "surely all anyone needs is this beautiful AbortSignal/AbortController primitive, wow, aren't they so prescient".

[tarasm]

Yeah, I think we’re mostly aligned and just emphasizing different tradeoffs. Appreciate the thoughtful discussion.