10 ms·

It might be worthwhile to expand a bit in the docs on the problems you see with JS concurrency (why you think it sucks, maybe some examples) and then show how

It might be worthwhile to expand a bit in the docs on the problems you see with JS concurrency (why you think it sucks, maybe some examples) and then show how ts-chan fixes those problems.

joeycumines 3y ago
That's a good idea, thanks :) Honestly, I've been struggling to come up with examples that aren't extremely contrived, but are still self-contained enough to easily demonstrate. It might actually be easier to just document patterns, though.
artisin 3y ago
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
pyrolistical 3y ago
Agreed. I don’t know go. So I still don’t understand what this is trying to solve
- joeycumines 3y ago
  I think y'all have very fair points, for the record. Unfortunately it is a lot easier to write documentation for an audience that shares the same context / background / experience. The README was written with an audience in mind consisting primarily of those familiar with Go (or more convoluted "communicating sequential processes" implementations), who were frustrated that things that are very easy in Go, are so much harder in JS. It's not something I considered deeply, but I was imagining that it was unlikely that someone would be searching for "channels in JS" without a base level of understanding. I work/have worked with some pretty talented people, but (in the past) I've found it difficult to convey the value of the sorts of patterns that `ts-chan` is intended to enable, to those without first-hand experience with such patterns. Documentation is hard :P
  - yunohn 3y ago
    I’m pretty sure you could articulate how exactly this “better” pattern works versus the default “bad” one. Right now the readme is a pile of illegible jargon to me as a non-go person.
    - joeycumines 3y ago
      Sure, I intend to give it a shot. I will say though, I personally get the impression that attempts at "concurrency" in JavaScript (in production code) are quite rare, which I attribute to how difficult it is. That is to say, I don't know if there really _is_ a "default pattern".
      - yunohn 3y ago
        I think it would be useful to generally explain what these primitives do and how they interact with each other. A lot of JS/TS users haven’t used golang, but would appreciate a better solution if they understand it (me included). Regarding the default vs better, a comparative example with a real concurrent task coded with/out your library would be my preferred way to understand it clearly.
29athrowaway 3y ago
Real JS concurrency = Worker threads, which already make use of channels for communication. Promises are for asynchronous programming, which are not concurrent.
joeycumines 3y ago
First instalment of docs/examples complete, feedback appreciated: https://news.ycombinator.com/item?id=38183241 https://news.ycombinator.com/item?id=38183241

It might be worthwhile to expand a bit in the docs on the problems you see with JS concurrency (why you think it sucks, maybe some examples) and then show how ts-chan fixes those problems.

joeycumines 3y ago

That's a good idea, thanks :) Honestly, I've been struggling to come up with examples that aren't extremely contrived, but are still self-contained enough to easily demonstrate. It might actually be easier to just document patterns, though.

artisin 3y ago

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

pyrolistical 3y ago

Agreed. I don’t know go. So I still don’t understand what this is trying to solve

joeycumines 3y ago
I think y'all have very fair points, for the record. Unfortunately it is a lot easier to write documentation for an audience that shares the same context / background / experience. The README was written with an audience in mind consisting primarily of those familiar with Go (or more convoluted "communicating sequential processes" implementations), who were frustrated that things that are very easy in Go, are so much harder in JS. It's not something I considered deeply, but I was imagining that it was unlikely that someone would be searching for "channels in JS" without a base level of understanding. I work/have worked with some pretty talented people, but (in the past) I've found it difficult to convey the value of the sorts of patterns that `ts-chan` is intended to enable, to those without first-hand experience with such patterns. Documentation is hard :P
- yunohn 3y ago
  I’m pretty sure you could articulate how exactly this “better” pattern works versus the default “bad” one. Right now the readme is a pile of illegible jargon to me as a non-go person.
  - joeycumines 3y ago
    Sure, I intend to give it a shot. I will say though, I personally get the impression that attempts at "concurrency" in JavaScript (in production code) are quite rare, which I attribute to how difficult it is. That is to say, I don't know if there really _is_ a "default pattern".
    - yunohn 3y ago
      I think it would be useful to generally explain what these primitives do and how they interact with each other. A lot of JS/TS users haven’t used golang, but would appreciate a better solution if they understand it (me included). Regarding the default vs better, a comparative example with a real concurrent task coded with/out your library would be my preferred way to understand it clearly.

29athrowaway 3y ago

Real JS concurrency = Worker threads, which already make use of channels for communication. Promises are for asynchronous programming, which are not concurrent.

joeycumines 3y ago

First instalment of docs/examples complete, feedback appreciated: https://news.ycombinator.com/item?id=38183241 https://news.ycombinator.com/item?id=38183241