There's a library for Node called Zx (https://github.com/google/zx) that provides a more shell-liked interface for Node.
I've been working on something in Python, inspired by Zx and Xonsh (https://xon.sh/), with syntax like this:
from pathlib import Path
from pyshell import Pipeline
args = ["123", "456"]
f = Path("out.txt")
with Pipeline() as p:
p.exec("a") | p.exec("b", *args) | p.exec("c", "x", "y") >> f
Is this something you'd use? It's slow going for me because it basically involves writing a compiler and I have approximately zero idea of what I'm doing. Knowing that other people would find it useful helps me stay motivated to keep working on it! Or if someone who theoretically is the primary audience doesn't find it useful, it might mean that I should spend my energy on other things.
Not an official Google product of course but ...
>Bash is great, but when it comes to writing more complex scripts, many people prefer a more convenient programming language. JavaScript is a perfect choice, but the Node.js standard library requires additional hassle before using. The zx package provides useful wrappers around child_process, escapes arguments and gives sensible defaults.
I'd love some day to have the power-shelly dream of an object oriented platform. But I don't want to renounce all the cli tools I know & love & switch to a strange new platform to get it.
I think the major difference between Python and JS "environments" is that with Python virtualenvs, the `python` binary itself is (usually?) part of the environment. But with JS, you generally have one `node` installed on your system, and then multiple "environments" aka projects each with their own yarn.lock and package.json. Of course you can have multiple `node` versions using something like `nvm`, but it's definitely less coupled to the per-project environments than `python` is to whatever virtualenv dependencies you have.
there's also a deno port[2].
More from the fringe, I'm quite enjoying zx, a really nodejs powered scripting environment. https://github.com/google/zx
Covered somewhat in ZX 3.0 https://news.ycombinator.com/item?id=28195580 (189 points, 8 months ago, 163 points)
I've started using that instead of bash script and js/node/deno scripts. it's kind of a nice combination of things.
the only pain with this is writing to files. > doesn't just work.
But JavaScript, as an actual scripting language, has been pretty primitive. It is only now starting to become a real candidate for actual scripting. There's imo crufty not very great options like shelljs[1]. But by adding a tagged-template string for system() for calling things, and a little bit of standard library, the recent ZX has made JS a much more interesting & competent scripting language[2].
I like the idea of the topic, exploring it. But the author feels off in a number of places.
> What TypeScript showed is that you could join together the idea of a flexible lightweight (and optional!) type system onto an existing programming language, and do so successfully. . . .The question then is - what if you created a programming language from the start to have this kind of support?
Personally I just don't think languages matter very much. They're very similar, by & large. They have different tooling, packaging, somewhat different looks/feels for executing code, and their standard libraries are different. But TypeScript is popular & fast at least 90% because it is JS, because it works with JS things. Arguing that we should try to recreate TypeScript apart from JS sounds like a mind blowing waste of time. Also, Deno has good integrated TypeScript support.
On the topic of easy parallelism, JavaScript promises are imo quite easy to stitch together & use & quite available.
One of the main issues I see with easy-parallelism is that it's too easy: there's too many cases for uncontrolled parallelism. Throwing tarn.js or other worker-pools at problems seems all too common. But one is still left stitching together each pool/stage of work. I'd like to see SEDA[3] like architectures emerge, and perhaps get added to something like ZX standard library.
[1] https://github.com/shelljs/shelljs
[2] https://github.com/google/zx
[3] https://en.wikipedia.org/wiki/Staged_event-driven_architectu...
There's a couple efforts like shell.js[1] or the far simpler/more-contemporary zx[2] to give shell-scripting like ease to js. zx's core is just at tagged template string for running system() calls, basically, ex: $`echo 2+2`. I still find the experience pretty sub-par compared to how shell & scripting first languages like Perl are.
Perl is just super powerful, keeping a foot in a more user-land like environment, versus the totalizing experience of libraries. Why do you need to pick a http client library to use when everyone is already quite intimate with curl & it's already on the system? Somehow coding keeps taking more turf, but I feel like Perl's scripting was extremely glorious & largely un-reproduced. Perl is still some of the best "glue" the planet has seen. And glue, as we've read a couple times on HN[3][4], & which I agree with, is really important, dominates what we build.
To the topic itself, as a Debian user, I appreciate Perl, but I wish it weren't on my OS taking up ~20MB of space & being more & more offbeat, but it's probably never going away. Not sure why it irks me that my computers will all need that ~20MB of Perl + Debian perl libraries. And it is pretty cool how debuggable & visible the Debian tools often are, because they're scripts, not compiled programs, by & large. But there's a lot of operators to lookup & a lot of implicit variables to remember in Perl programs, and it's a reminder how offbeat Perl is, every time I poke my head in.
[1] https://github.com/shelljs/shelljs
[2] https://github.com/google/zx
[3] https://news.ycombinator.com/item?id=27486706 https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft...
[4] https://news.ycombinator.com/item?id=27880183 https://www.oreilly.com/radar/thinking-about-glue/
await $`dep deploy --branch=${branch}`
…
await $`mkdir /tmp/${name}`
Biggest pain points in my opinion in pure bash is flow control, string manipulation, arrays, and looping.