Hacker News Reader

Comment by CGamesPlay | Hacker News Reader

I'm really unclear on what repository you're commenting on. The first example shows an example of executing commands in parallel, and does 3 jobs with 1 await.

  await Promise.all([
    $`sleep 1; echo 1`,
    $`sleep 2; echo 2`,
    $`sleep 3; echo 3`,
  ])

The only `exit 1` in the README is an example on how to handle cases where your job fails, so don't really understand what your complaint is.

View on HN

Okay, but why would I do that instead of just

    sleep 1 && echo 1 &
    sleep 2 && echo 2 &
    sleep 3 && echo 3 &
    wait

and be done with it? Now I don't need to prepend 'await $`...`' in front of every other command.

when I write scripts in js or python over bash, its to leverage their access to data structures, error handling, and libraries. Often I use TypeScript, because types are good and concurrent i/o is a first class feature.

This means that promise.all probably looks something more like

  const lastWeek = DateTime.now().minus({ days: 7 }).toISOString()
  const pods = JSON.parse(await $`kubectl get pods -o json`)
  useValidate(pods, isKubeCtlPodList)
  await Promise.all(
    pods.filter(pod => !protectedPods.includes(pod.name))
        .filter(pod => target.test(pod.name))
        .filter(pod => pod.created < lastWeek)
        .map(pod => $`kubectl delete pod ${pod.name}`)
  )

Id certainly encapsulte my calls, parsing, and validation differently in real code, but you get the gist.

In shell I can wrangle jq, date, xargs and get the same result; only this is waay easier to write, gives me validation and usable error messages, and can be altered much more easily than shell.

I write complex bash scripts somewhat often. They can be quicker to write, they are great for one-offs. But if I'm coming back to something non-trivial or if its getting deployed into production I want a language like js or python (or nearly any other language. C++, OCaml, Java all help more than they hinder).

If process in the middle exists with non zero exit code, your whole script won't exit with non zero exit code. You have to collect exit codes and check them.

The whole thing will exit if any of those fail because of the double ampersands. Semicolons are the ones that ignore exit codes.

Things like this are why I don't love bash. Whether a script will fail if a step fails is too important to be hidden behind a single character change in a place most people ignore.

that’s just ignoring all the other benefits, or pitfalls of bash that you have to worry about. This project is not about enabling better parallelism.

(I’ve written massive bash scripts, and now strongly prefer Ruby / python / whatever is available in the system)

Also I think you need to add a trap to make sure the processes exit on ^C.

I agree that for complex scripts bash isn't ideal. But my criticism was about unnecessarily verbose syntax. Bash is synchronous by default, this project is the exact opposite.

I totally get your point! As someone who is not coming from JS, I agree with you!

But you must understand that I/O in JS is async, it's how the language is build! People who are advanced in async programming find this very comfortable.

Reply on news.ycombinator.com