joeycumines's comments

That one is actually pretty easy in JavaScript - in the past I've implemented the same sort of behavior using async generators.

(I also like Go's time.Ticker behavior quite a lot)

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".

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

Ah, that example is demonstrating an internal mechanism used to ensure the high-level asynchronous API calls take at least one tick of the event loop to complete.

There is no `result` variable - I was just attempting to convey that "some async stuff happens, then it waits if we can't verify that it's not the same tick as when the call started". The "async stuff", in the actual implementation, is sending or receiving.

I actually considered including one in the README, but there were (are) lots of other topics to consider.

The tl;dr is that there is some cross over, but the use cases and patterns they support are largely different. Message channels are two-way, channels are one way. (I believe) message channels are 1-1, while `ts-chan`'s channels are n-n, though each send corresponds to a single receive.

The primary use case I aim to address is coordination between independent, asynchronous operations (concurrency in JavaScript). Having an analogue to Go's "select statement" is fairly key to that, and I am not quite sure how to articulate the value it provides, but it does not overlap with message channels.

Example using a single channel: `ts-chan` may be used to implement a set of workers, which accept requests from n sources (e.g. incoming http requests in a web server), then perform some operation, as a mechanism to bound the concurrency of that operation. Personally, I find it much easier to model it as:

1. Start the desired number of workers

2. Wire up workers to await incoming requests then process them, in a loop

3. Send requests to said workers

Rather than (for example) tracking the number of running operations, starting a new worker only if possible, after enqueuing the operation, then having the workers need to operate like "check for any work, increment number of operations, perform operation, check for any work (loop), otherwise decrement number of operations".

The `ts-chan` pattern (which is, really, just a Go pattern) also makes it much easier when the requirements are more complex, e.g. if the requester needs to wait for a response, and might timeout before the operation is even started - in which case the operation should be cancelled.

I should probably include demonstrative examples for all that, heh.

I've been considering adding a `select` function, but I was concerned with the overhead of recreating the select case each time, and wanted to reserve it for a time once I've mulled over my options (I'm aiming to avoid making breaking changes, even though it's pre-v1).

With receives, there's a value attached, and that presents some difficulties regarding typing (for TypeScript).

You have given me an idea, however: I _might_ be able to wrangle together a mechanism that avoids making it a two-step deal (get the index, then resolve the type). It'd probably support only a subset of the functionality, though.

It's on my list to add a simple example to the README using the `Chan` class. Communicating with a single channel (with or without abort support) is very simple, and I'm happy with the API for that.

The concurrency comes from providing mechanisms to communicate between independent, asynchronous chains of operations.

Here is an example, that I based on an example from within the Go spec: https://github.com/joeycumines/ts-chan/blob/main/examples/co...

Here is the same example in Go: https://github.com/joeycumines/ts-chan/blob/main/examples/co...

The JS example is, obviously, much slower, and is fairly contrived - I wouldn't expect anyone to actually want to do that, specifically. The JS one is more complicated primarily because I used it in a benchmark, so needed a mechanism to stop the concurrent, asynchronous chains of operations, once it reached the target number of primes.

I hope that explains it for you.

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.