Hacker News Reader

Comment by joeycumines | Hacker News Reader

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.

View on HN

It is not what is widely understood as concurrency and the documentation for Promise type is clear in that regard.

Nothing happens concurrently (at the same time), only asynchronously (at different times).

From the documentation:

> Note that JavaScript is single-threaded by nature, so at a given instant, only one task will be executing, although control can shift between different promises, making execution of the promises appear concurrent. Parallel execution in JavaScript can only be achieved through worker threads.

I hope that explains it for you.

Concurrency != Parallel execution

In JS, without worker threads or similar situations, you don't have real race conditions. Therefore, concurrency primitives like mutexes, read/write locks, condition variables, barriers, semaphores, etc. are not necessary. Or Go-like channels.

You can use a global variable and it will be fine because it won't be accessed simultaneously.

So then how is this not cargo culting Go? imitating the observable parts of Go without truly understanding what it does?

What makes data races not a "real race condition"?

Anyhow, do what you will. I don't get the impression that you are genuinely interested in this topic.

Thanks for conceding the point. Have fun.

Excuse my multiple comments, just trying to understand this better since I’m very intrigued by your library.

What does the JS “if x != x” check do? I don’t see the equivalent in the golang example?

From the concurrent prime sieve example?

That's just something I copy and pasted from the documentation for the benchmark package I used. Allegedly, it is to prevent "certain compiler optimisations", which is something I'm familiar with when it comes to benchmarking Go code, for example.

I lack specific knowledge as to whether it's actually necessary, sorry :)

Ah, gotcha!

I thought maybe it was something to do with concurrency, and somehow x is affected by a race condition there.

Reply on news.ycombinator.com