3 ms·

I somewhat disagree with this take, as I felt the intro and "The microtask queue: a footgun" [1] section in the README does an adequate job of laying out the 'w

I somewhat disagree with this take, as I felt the intro and "The microtask queue: a footgun" [1] section in the README does an adequate job of laying out the 'why' and the problems with JS's concurrency model. However, it does presume some understanding of Go's channels, so a more explicit example contrasting ts-chan with native JS concurrency could better clarify its benefits for those less familiar. Granted, there is an /example directory, but the benchmarking complexity muddles the readability. Regardless, upon a quick run-through, it looks to be an A-grade library that seems promising for practical use, plus well-referenced, composed, and quite thorough. [1] https://github.com/joeycumines/ts-chan#the-microtask-queue-a-footgun https://github.com/joeycumines/ts-chan#the-microtask-queue-a...

rpbiwer2 3y ago
Maybe I'm dumb but that section didn't explain the problem to me in the slightest.
- artisin 3y ago
  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.
Aeolun 3y ago
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.
- joeycumines 3y ago
  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.
  - Aeolun 3y ago
    > 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.
    - _lvbh 3y ago
      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

rpbiwer2 3y ago

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

artisin 3y ago
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.

Aeolun 3y ago

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.

joeycumines 3y ago
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.
- Aeolun 3y ago
  > 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.
  - _lvbh 3y ago
    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