Hacker News Reader

Comment by miohtama | Hacker News Reader

Zx is good if JavaScript is only language you know. If you have ability to program or learn other programming languages, Python with packages like Shell and Plumbum might be better choices for shell scripting tasks that outgrow shell.

- Python code with Shell is easier to read ana write

- No nees to carry async/await keywords thru the code

- Powerful plain text manipulation in the stdlib

https://pypi.org/project/python-shell/

https://plumbum.readthedocs.io/en/latest/

View on HN

Powershell is also available for Linux these days, and well Powershell is awesome.

Not sure how I feel about needing Node.JS to run shell scripts…

> Python code with Shell is easier to read and write

That is pretty subjective

Yes. I started programming in JavaScript in 1999 and Python in 2003, so it is my subjective opinion based on mastering the both languages. There are some factual and objevtive features making Python syntax more friendly, but it is a worth of a blog post to explore. And in the end there is no point, as JavaScript maximalists would not care.

Maybe, but the main advantage of `zx` (at least for me) is that I don't have to manage another language environment. I can keep everything contained within Node :)

The problem is Node, especially all the packages that you’ll end up using under the hood, it’s seems quite risky especially if you don’t have super tight control over your Node SBOM.

Would be a bit more interesting to me if it was a JS shell built from the ground up without the entire mess of the Node package dependency baggage.

While I agree that Node's ecosystem is not the best, it's what we have in the frontend world.

If you're working on a Node-based service or React app, you already have to deal with Node and its package ecosystem. Adding a couple of extra MB (or even KB, depending on package reuse) on top of your existing chain of dependencies is a tiny con to the huge benefit of not having to do logic in Bash :)

The problem is that you don’t always know what is actually being executed, shell scripting is risky as it is without the rabbit hole that is the Node dependencies system.

There's always WSH if you're on Windows and will settle for ECMAScript 3. No external dependencies or runtime needed.

zx has a small dependency tree, 12 packages marked as "@types" and 36 regular packages[0].

If you are fluent in Node, it should be easy to avoid further dependencies.

0: https://arve0.github.io/npm-download-size/#zx

What is there to manage? Python comes built-in with pretty much every distro, and you only have to install one package.

There is also xonsh[0] if you want an similar experience to zx to mix bash and python.

[0] -- https://github.com/xonsh/xonsh

Maybe but Python is sloooow and its type annotation situation is pretty poor.

I would recommend using Deno. It has the following advantages:

* Uses Typescript which gives you a great static typing system.

* Runs via V8 so it's about a million times faster than Python.

* Single statically linked binary with no project setup files required (package.json/dependencies.txt) makes it about a million times easier to deploy than either Node or Python. Especially on Windows.

* You can still use third party libraries even without a project file and you get IDE integration.

It's the clear winner at this point. Someone has even made a version of zx for it:

https://deno.land/x/zx_deno@1.2.2

I’ve found Python is just fine performance-wise for CLI tools. What bad experiences have you had with it? I’ve mostly used click.

Python interpreter by itself is fast, it spawns in a few milliseconds, but it can slow to a crawl if you need libraries, and easily take a few seconds.

However, situation is similar with nodejs.

Startup time is very slow. I just tested on my system and cold startup was 1 second (!) and hot 180ms. Vs 80ms and 64ms for Node.

Also it obviously depends what your CLI tool is doing. Just because something is a CLI tool doesn't mean it doesn't do much stuff and therefore performance doesn't matter.

For example Scons is a CLI tool. It's a build system written in Python. Everybody abandoned it because it was dog slow.

Mercurial is a CLI tool. It's a VCS written in Python. Most people have abandoned it partly because it is slow (and partly because Github exists).

You can read about Mercurial's troubles with Python performance here:

https://www.mercurial-scm.org/wiki/OxidationPlan

> Performance is a significant pain point with Python. There are multiple facets to the performance problem:

> * Startup overhead

> * General performance overhead compared to native code

> * GIL interfering with parallel execution

> It takes several dozen milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take well over 100ms just to effectively get to a Mercurial command's main function. Reports of over 250ms are known. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users.

How much difference does 180 ms vs. 64 ms make for your use case?

In scripts designed to be run directly at a bash prompt by humans, the difference would absolutely be noticeable.

It is definitely noticeable even when you run a command once. But it really becomes a problem when your command is run lots of times as part of some other system.

For example if you're using Python to process a lot of files via Make (something my work's build system does unfortunately) then it can end up costing 10s of seconds which is kind of insane.

Wow, plumbum, despite it's unfortunate name, looks awesome. I will definitely try it next time I write a script.

how is the name unfortunate? from the site:

> Plumbum (Latin for lead, which was used to create pipes back in the day)

And yet it sounds like a thicc ass.

I confess to being quite amazed that you saw an innuendo somewhere I didn't.

Yes, but the name choice was quite intentional and probably giggle inducing. This is about as toilet humor as it can get.

According to the Classical Latin pronunciation I learned in school, this is "ploom-boom" rather than "plum-bum."

I wonder if your comment says more about how you choose to see the name rather than any inherent meaning.

Personally, I only see it as the old name for lead. Interesting to see how others are wired.

I guess if you've never learned about the word 'plumbing' before?

That's fair. My Latin is non-existent, and I clearly was too eager to look at example source instead of reading the description. I'll take my criticism and walk away.

Reply on news.ycombinator.com