Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zx 3.0

github.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Zx 3.0

#151

Post by rickstanley »

gbear0 wrote: post #145
FinalBriefing wrote: post #118

Earlier quoted context omitted.

It is _a_ perfect choice. I know a bit of bash, but I'm always looking up how to do things I know are simple in JS. I would love to be able to write scripts in JS because I'm faster with it, and I find it easier to read.

in case anyone is looking to do this, it's as easy as doing the following #!/usr/bin/env node console.log("Hello World!");

In case anyone wondering how this is valid JS:

- https://tc39.es/proposal-hashbang/out.html

- https://github.com/tc39/proposal-hashbang

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Zx 3.0

#153

Post by Stampo00 »

another-dave wrote: post #88

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…

If you wrote your script against v1.7 and now they're on v3, you can still run your script. The v1.7 source and binary haven't disappeared. It's still available and work exactly the same as when you wrote your script.

Re: Zx 3.0

#155

Post by MisterTea »

striking wrote: post #130
rurban wrote: post #90

Earlier quoted context omitted.

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)

Couldn't you redirect the stdout/error file descriptors to achieve the same thing?

Re: Zx 3.0

#156

Post by asveikau »

cfeliped wrote: post #142
hulitu wrote: post #122

Earlier quoted context omitted.

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.

My understanding is that sh is a specification, not an implementation. Most images will either have bash or ash installed. ash, being lightweight, is the choice of alpine and related distros.

This is a bit of a Linux specific view of the universe. Yes posix has a standard for how sh should work. But there were specific implementations of sh, and you would get those on commercial Unix or *BSD.

Later shells came in and filled some gaps. OpenBSD still has ksh by default. Linux distros had bash as their /bin/sh.

Re: Zx 3.0

#157

Post by arve0 »

dogma1138 wrote: post #7
alexghr wrote: 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.

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

Re: Zx 3.0

#158

Post by cfeliped »

asveikau wrote: post #156
cfeliped wrote: post #142

Earlier quoted context omitted.

My understanding is that sh is a specification, not an implementation. Most images will either have bash or ash installed. ash, being lightweight, is the choice of alpine and related distros.

This is a bit of a Linux specific view of the universe. Yes posix has a standard for how sh should work. But there were specific implementations of sh, and you would get those on commercial Unix or *BSD. Later shells came in and filled some gaps. OpenBSD still has ksh by default. Linux distros had bash as their /bin/sh.

I didn't know that. Thank you for the explanation!

Re: Zx 3.0

#159

Post by reddit_clone »

tgsovlerkhgsel wrote: post #72

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…

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.

Re: Zx 3.0

#160

Post by eyelidlessness »

otabdeveloper4 wrote: post #92

> await await await await Oh yeah, right, because the first thing that comes to mind when writing bash scripts is "I sure wish there was more 'await' noise in all this code!" Anyways: 'async' in the Python and Javascript sense was a mistake, future generations will think we were insane to adopt it. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Given Promises and callbacks have always been pervasive in JS—that it’s always been heavily asynchronous—I can’t imagine thinking async/await was a mistake. It’s a drastic ergonomic improvement over both, and it also drastically improves debugging and error stacks.

Adding it to a language where IO is typically blocking with other ergonomic concurrency mechanisms, that I can imagine being somewhat controversial.

It would be good if async weren’t infectious, but as a sibling comment said that was already the case with Promises and callbacks.

It would maybe also be better if concurrency was the default behavior and keeping a reference to a promise was the explicit syntax, but I could see downsides to that. It potentially hides/encourages excessive use of expensive calls. And implicit concurrency is a potential source of many bugs.

Post reply on HN