Maybe I'm dumb but that section didn't explain the problem to me in the slightest.

Not necessarily, and after giving it more thought, I somewhat retract my previous comment. You do make a good point; it's explained well, but not in concrete terms without assumptions. So, I'll take a stab at it: The core idea is that async functions A and B can communicate through Chan instances, with the Select class overseeing multiple Chan operations, waiting for one to be ready before proceeding. While ts-chan might seem unnecessary for just two async functions, what if you had to manage 8, 16, 32, or more? At some point, Promise.all won't cut it, and that's where ts-chan comes to the rescue. It defines a protocol for channels to better manage communication between asynchronous functions in JS, offering a structure similar to how goroutines communicate in Go.

The only thing that told me was that the author is used to Go primitives and doesn’t like switching to Javascript.

That might be completely wrong, but it’s the impression I get when someone says that something the rest of the world uses without issue sucks.

I might be completely wrong, but the impression I got from your comment is that you haven't been exposed to many implementations using non-trivial concurrency :)

Fair call though, I guess. It doesn't really matter, but I'm certainly used to TypeScript and JavaScript.

> you haven't been exposed to many implementations using non-trivial concurrency

That is entirely accurate. I struggle to imagine scenarios in which I’d need two parallel routines to communicate with each other.

Maybe because we probably shouldn’t be doing that in JavaScript. I primarily use Go and work with Go routines often but I’ve never wanted to do anything remotely close to it in JavaScript. If I wanted proper concurrency, I would be using Go, not JS