4 ms·

As annoying as having to write "await" in front of everything is (probably should have a variant of $ that's synchronous), the ability to effortlessly implement

As annoying as having to write "await" in front of everything is (probably should have a variant of $ that's synchronous), the ability to effortlessly implement parallelism is something that all other common scripting (and many "full") languages seem to lack. Even Go, that prides itself on the good support for parallelism, fails once you actually want go get results back. If this were paired with some way to also display the status/output of multiple commands in parallel, this would be the ultimate toolkit to write scripts. If you look at apt, for example: Does it really have to wait for the last package to be downloaded before installing the first? Is there a good reason, on modern SSD-based computers, to not parallelize the installation of multiple packages that don't depend on each other?

rurban 5y ago
using sh is usually preferred: somecmd & someothercmd & wait runs the two commands in parallel and waits for both. no need for await. to run in serial replace & with && and skip the wait
- tgsovlerkhgsel 5y ago
  Huh, neat, didn't know "wait". Thanks! Still doesn't let you easily get the output of the two commands, but a good start.
  - 10000truths 5y ago
    You can just use files as a temporary buffer: (/my/bg_producer1 > /shm/file1) & (/my/bg_producer2 > /shm/file2) & /my/longrunningfgjob wait (/my/consumer1 < /shm/file1) & (/my/consumer2 < /shm/file2) & wait
- striking 5y ago
  You lose the ability to know whether they succeeded or failed, though. Like most things given to you for free by the shell in shell scripting, it's only like halfway to a real solution. (If you know how many subshells you started and won't get confused by which is which, you can use `wait -n && wait -n && ...` in bash)
  - MisterTea 5y ago
    Couldn't you redirect the stdout/error file descriptors to achieve the same thing?
q3k 5y ago
> Even Go, that prides itself on the good support for parallelism, fails once you actually want go get results back. It's doable if you're willing to build a very thin abstraction over whatever you're trying to parallelize keeping in mind all possible edgecases [1] and how you'd like to handle them. A generic `run N things in parallel and collect their results` function would be nice, but would probably end up being quite unwieldy in comparison to just writing out a purpose-specific function for what you exactly need. [1] - Error handling, timeouts/cancellation, maximum amount of processes running in parallel, wait-for-full-join vs. returning results as they appear, introspection of currently running subordinates, subordinate output streaming/buffering/logging, ... A lot of things to consider when you're trying to build something universal, but that are easy to solve/ignore when you're building something purpose-specific with known constraints.
- tgsovlerkhgsel 5y ago
  That's the thing though... if the options are "write and test 30 lines of custom parallelism code to handle this stuff" or "everyone waits twice as long for their results", in practice most developers choose the latter. Imagine if instead of that, you could do: foo, bar, []err := await getFoo(), getBar() if len(err) > 0 { return nil, nil, fmt.Errorf("Frobnication failed: %s", err) } return foo, bar, nil Of course, JavaScript having exceptions as the main error-raising approach and `await` supporting them makes that a lot easier.
otabdeveloper4 5y ago
Awaiting on every line is hardly parallelism.
- tgsovlerkhgsel 5y ago
  The code in the main readme (https://github.com/google/zx https://github.com/google/zx) has an example of parallelism (the Promise.all line).
Siira 5y ago
Take a look at GNU Parallel. It’s magnificent.
reddit_clone 5y ago
Give Perl6/Raku a shot if you haven't yet. IMO, it is pretty much the best-of-all-worlds language that is still accessible. (Meaning not exotic like Haskell or Erlang..) The concurrency is beautifully painless.

rurban 5y ago

using sh is usually preferred: somecmd & someothercmd & wait runs the two commands in parallel and waits for both. no need for await. to run in serial replace & with && and skip the wait

tgsovlerkhgsel 5y ago
Huh, neat, didn't know "wait". Thanks! Still doesn't let you easily get the output of the two commands, but a good start.
- 10000truths 5y ago
  You can just use files as a temporary buffer: (/my/bg_producer1 > /shm/file1) & (/my/bg_producer2 > /shm/file2) & /my/longrunningfgjob wait (/my/consumer1 < /shm/file1) & (/my/consumer2 < /shm/file2) & wait
striking 5y ago
You lose the ability to know whether they succeeded or failed, though. Like most things given to you for free by the shell in shell scripting, it's only like halfway to a real solution. (If you know how many subshells you started and won't get confused by which is which, you can use `wait -n && wait -n && ...` in bash)
- MisterTea 5y ago
  Couldn't you redirect the stdout/error file descriptors to achieve the same thing?

q3k 5y ago

> Even Go, that prides itself on the good support for parallelism, fails once you actually want go get results back. It's doable if you're willing to build a very thin abstraction over whatever you're trying to parallelize keeping in mind all possible edgecases [1] and how you'd like to handle them. A generic `run N things in parallel and collect their results` function would be nice, but would probably end up being quite unwieldy in comparison to just writing out a purpose-specific function for what you exactly need. [1] - Error handling, timeouts/cancellation, maximum amount of processes running in parallel, wait-for-full-join vs. returning results as they appear, introspection of currently running subordinates, subordinate output streaming/buffering/logging, ... A lot of things to consider when you're trying to build something universal, but that are easy to solve/ignore when you're building something purpose-specific with known constraints.

tgsovlerkhgsel 5y ago
That's the thing though... if the options are "write and test 30 lines of custom parallelism code to handle this stuff" or "everyone waits twice as long for their results", in practice most developers choose the latter. Imagine if instead of that, you could do: foo, bar, []err := await getFoo(), getBar() if len(err) > 0 { return nil, nil, fmt.Errorf("Frobnication failed: %s", err) } return foo, bar, nil Of course, JavaScript having exceptions as the main error-raising approach and `await` supporting them makes that a lot easier.

otabdeveloper4 5y ago

Awaiting on every line is hardly parallelism.

tgsovlerkhgsel 5y ago
The code in the main readme (https://github.com/google/zx https://github.com/google/zx) has an example of parallelism (the Promise.all line).

Siira 5y ago

Take a look at GNU Parallel. It’s magnificent.

reddit_clone 5y ago

Give Perl6/Raku a shot if you haven't yet. IMO, it is pretty much the best-of-all-worlds language that is still accessible. (Meaning not exotic like Haskell or Erlang..) The concurrency is beautifully painless.