Live data from Hacker News

Zx 3.0

github.com

121–130 of 169 posts

Re: Zx 3.0

#121

First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already. Great that it's under active development, but changes to my scripts are infrequent and slow. I wouldn't want to be touching an old script on a server somewhere saying "How do I do X in ZX again?" and everything I find online is now for v15 while I'm still on v3. Maybe if it had plans around…

> First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already. Would you feel better if they called version three v1.9 instead?

Given that 3 and 1.9 have a completely different semantic meaning, they might.

Re: Zx 3.0

#122

In my first job I gave a try at using Python for scripts. It was a terrible idea, as I now had 3 problems instead of 1: 1 - Writing scripts, plus: 2 - Installing Python in every host that needed to run those scripts 3 - Maintaining Python and the necessary dependencies up to date in each host / container. (2) and (3) are trivial when done just once in your own computer, but end up being a huge time sink for larger he…

Bash just sort happened to be the lowest common denominator in most unix style environments. Because it just sorta ended up being the default. Unix ended up being this different thing where each distro seems to be kind of unique. Then on top of that they are very easy to customize. So while one distro you can assume a particular python level the next disto python is totally optional. Mix in containers and docker imag…

I thought that was sh (i.e. bourne shell). As far as i remember bash is not the default shell on a lot of unices.

Re: Zx 3.0

#123
post #119
post #111

> Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice um… what?

What is the nature of your outrage exactly? Bash is very difficult as a language to write code in. JS is very familiar to a lot of developers and its syntax is orders of magnitude easier to understand than Bash.

The prejudice against JS developers is that they are seen as low class janitorial code monkeys by ‘real programmers’. It hurts these people even more because the language just succeeds and succeeds despite all the hate.

Re: Zx 3.0

#124
post #108
post #57

Earlier quoted context omitted.

What I don’t like about backticks in Ruby is that they “ignore” errors in commands you run. It’s up to the program author to remember to check $? for the last executed command’s exit status. And guess how many times the average Ruby script using this feature implements error handling? Usually it’s totally forgotten. To be safe, abstractions that make it easy to shell out must also: - escape all variable interpolation…

In that case, welcome to Next Generation Shell (I'm the author), which actually cares about errors when running external programs. Yes, I mean much more than naive "non-zero is error" because that's just not true in many cases. https://ilya-sher.org/2017/01/28/ngs-unique-features-exit-co...

I do not want to sound like an oldtimer but even command.com had "if %errorlevel%"

Re: Zx 3.0

#125
post #111

> Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice um… what?

yeah same. As a front-end webdev who writes JS frequently, I've _never_ written shell scripts and thought "Wow, I'd really rather use JavaScript for this"!

Not saying it doesn't happen, just that it hasn't been my experience.

Re: Zx 3.0

#127

In my first job I gave a try at using Python for scripts. It was a terrible idea, as I now had 3 problems instead of 1: 1 - Writing scripts, plus: 2 - Installing Python in every host that needed to run those scripts 3 - Maintaining Python and the necessary dependencies up to date in each host / container. (2) and (3) are trivial when done just once in your own computer, but end up being a huge time sink for larger he…

JS is marginally better than Python for this, because tools for runtime and package version management are better for Node than for Python (proper lockfiles, local package folders, npm bundled with Node for installation, etc.). Still, zx isn't as nice as Ruby, which has backticks for calling shell as part of the language. So, you don't have to have a separate package installed, just the ruby runtine. But Perl is even…

Zx seems[1] to take advantage of the way template literals work in JS to do proper shell escaping of the parameters to prevent command injection. Is that handled by the Ruby and Perl backtick syntax as well?

[1] https://github.com/google/zx/blob/3.0.0/test.mjs#L30-L33

Re: Zx 3.0

#128
post #119

Earlier quoted context omitted.

What is the nature of your outrage exactly? Bash is very difficult as a language to write code in. JS is very familiar to a lot of developers and its syntax is orders of magnitude easier to understand than Bash.

The prejudice against JS developers is that they are seen as low class janitorial code monkeys by ‘real programmers’. It hurts these people even more because the language just succeeds and succeeds despite all the hate.

I would say that it's more that Bash is good at something and JavaScript is good at other things and just because they are technically scripting languages doesn't mean that they are naturally a good fit in each other's domains. The README's comment tends to point towards an idea that all languages that can write scripts are equally interchangeable and of all choices JavaScript is the perfect choice. To people that are working on a variety of scripts in numerous languages who all have individual advantages and disadvantages, it comes off as nonsense.

Re: Zx 3.0

#129
post #6

Earlier quoted context omitted.

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.

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

Re: Zx 3.0

#130
post #90

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 dis…

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

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)

Post reply on HN