4 ms·

The concurrency comes from providing mechanisms to communicate between independent, asynchronous chains of operations. Here is an example, that I based on an e

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/concurrent-prime-sieve/index.js 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/concurrent-prime-sieve/main.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.

yunohn 3y ago
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?
- joeycumines 3y ago
  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 :)
  - yunohn 3y ago
    Ah, gotcha! I thought maybe it was something to do with concurrency, and somehow x is affected by a race condition there.
29athrowaway 3y ago
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.
- joeycumines 3y ago
  Concurrency != Parallel execution
  - 29athrowaway 3y ago
    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?
    - joeycumines 3y ago
      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.
      - 29athrowaway 3y ago
        Thanks for conceding the point. Have fun.

yunohn 3y ago

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?

joeycumines 3y ago
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 :)
- yunohn 3y ago
  Ah, gotcha! I thought maybe it was something to do with concurrency, and somehow x is affected by a race condition there.

29athrowaway 3y ago

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.

joeycumines 3y ago
Concurrency != Parallel execution
- 29athrowaway 3y ago
  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?
  - joeycumines 3y ago
    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.
    - 29athrowaway 3y ago
      Thanks for conceding the point. Have fun.