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

ZX – A tool for writing better scripts

github.com

Post reply on HN
Print view View original

101–110 of 143 posts

Re: ZX – A tool for writing better scripts

#101

Post by Sammi »

Mawr wrote: post #50

Well this doesn't make much sense. If you rightfully find bash inadequate at some point, just switch to the next most natural tool - Python. Nobody's going to be surprised when they see a Python script. If you start feeling Python is inadequate too, then: 1) You're wrong, just stick to Python 2) If you're so bent on doing away with familiarity, at least get as much leverage as you can in return and use a "proper" lan…

Why should a nodejs dev have to pull in python? That is a heavy solution when you can script well in js already.

Re: ZX – A tool for writing better scripts

#102

Post by IshKebab »

Mawr wrote: post #50

Well this doesn't make much sense. If you rightfully find bash inadequate at some point, just switch to the next most natural tool - Python. Nobody's going to be surprised when they see a Python script. If you start feeling Python is inadequate too, then: 1) You're wrong, just stick to Python 2) If you're so bent on doing away with familiarity, at least get as much leverage as you can in return and use a "proper" lan…

Python's ok for this as long as you need 0 third party dependencies and it's a single file. As soon as you want to split into multiple files or import something that isn't part of the standard library then it becomes a total disaster.

I think Deno is a really good option here - better than ZX. You can use third party libraries easily, it works with IDEs, and it's trivial to install.

Re: ZX – A tool for writing better scripts

#103

Post by frizkie »

Mandatum wrote: post #86
cerved wrote: post #37

Earlier quoted context omitted.

It's asynchronous, which is pretty neat

A script, by its very nature, is synchronous. You run, you get a result. If you want a service, don't use a script.

This is pedantic to the point of being conversationally hostile.

Re: ZX – A tool for writing better scripts

#104

Post by josephg »

makeitdouble wrote: post #81
josephg wrote: post #18

Earlier quoted context omitted.

> There are far more JavaScript developers in the world than there are even Python developers I don’t think that’s true. Anecdotally when I was interviewing at a recruiting company (and we let candidates pick any language to be assessed in), Python was by far the most popular choice, chosen by about 60% of candidates or something like that. Java and JavaScript came after, followed by a long tail of languages like C#…

Is it a recruiting company, as it's main business is to recruit candidates ? Or was the core business something else and you were recruiting devs for it ? I think it's always difficult to get the bigger picture of the dev market through candidates. Many (rightfully) handle their career moves by themselves and will directly apply to companies that fit them, heavily biasing the movement observed from the company or thi…

Main business is (was) recruiting people for roles all over the place.

Re: ZX – A tool for writing better scripts

#105

Post by teo_zero »

dspillett wrote: post #80
teo_zero wrote: post #46

The first command of the first example is a cat|grep... How can I assume the author is an experienced script writer? In any case, ZX replaces some of the shell's usual quirks with its own different quirks: you have to manually expand * with glob() and ~ with os.homedir(), you can't build commands as strings without repeated calls to push(), etc.

> example is a cat|grep... How can I assume the author is an experienced script writer? Perhaps because they are writing documentation that can be understood be less experienced script writers as well as themselves, using a very common example seen everywhere? I find "cat full | ..." keeps the left-to-right flow of a command nicely, and is better understood by those less familiar with shell work than prepending " Yes…

> I find "cat full | ..." keeps the left-to-right flow of a command nicely

Sorry, I don't buy it.

You don't read files like this:

  cat file | less
And you don't compile C programs like this:

  cat hello.c | gcc -xc -
Actually using less, grep (and even gcc) as filters is more confusing to "those less familiar with shell work".

Re: ZX – A tool for writing better scripts

#106

Post by pwdisswordfishc »

pavlov wrote: post #82
hlandau wrote: post #56

>Write your scripts in a file with an .mjs extension in order to use await at the top level. If you prefer the .js extension, wrap your scripts in something like void async function () {...}(). Shebang scripts shouldn't have a file extension in the first place, so requiring one here is a dealbreaker. And having the file extension be used to switch between two different incompatible source formats is really a terrible…

I think this is a Node.js limitation, not a design choice by ZX. You could perhaps use a different JS runtime that doesn't have these admittedly esoteric file extension rules.

    node --input-type=module
This is not a design choice, this is laziness by ZX.

Re: ZX – A tool for writing better scripts

#107

Post by iLoveOncall »

hlandau wrote: post #66
iLoveOncall wrote: post #62

Earlier quoted context omitted.

> Shebang scripts shouldn't have Should not have or should not need to have? You can perfectly write a script with a shebang and an extension, stick it in your path, and use it without extension. Therefore, I fail to see how this is a "dealbreaker". Or is it just because "I don't like it!"?

So how am I supposed to put such a script in $PATH? e.g. if I hypothetically want to make a replacement for say 'ls', what am I supposed to do, force people to type 'ls.mjs' rather than 'ls'?

No, that's my point, every single shell I've ever used would resolve "ls.mjs" if you called "ls" and it's in your path...

Re: ZX – A tool for writing better scripts

#108

Post by lloeki »

Sammi wrote: post #99
Fragoel2 wrote: post #17

"[For writing complex scripts] JavaScript is a perfect choice". Not sold on that. Why should I choose it over Python, PHP or others?

Modern js is not what it was. Ergonomics of nodejs v20 are not in the same ballpark as node v6. A lot has happened since v12 even. Js definitely has become a pleasant language to script in. And it's sooooo much faster that python and Ruby.

> And it's sooooo much faster that python and Ruby.

That advantage becomes vanishingly small when the language task is to glue together a bunch of spawn/fork/exec to external processes.

If the glue code somehow needs actual heavy processing, that processing can be factored out into another program dedicated to that, leaving only glue code. Side effect: the heavy processing code immediately becomes composable!

Re: ZX – A tool for writing better scripts

#109

Post by x-cmd »

Hello everyone, I think I happen to have some experiences to share:

1. Five years ago, I developed my own version of zx/dax version using TypeScript. I call this project TypeShell.

2. In the past three years, I have written x-cmd, implemented by posix shell.

Please visit x-cmd at https://x-cmd.com. It is now close to the public beta version. It is still under construction, and the demo can tell some stories. It tries to enhance posix shell in various ways. Its installation tar.gz package is only 1.02MB (which can be optimized). Even with sh/awk/curl, it can do a lot of things. These features are called modules. And, through the self-contained pkg manager (do not require priviledge to install), x-cmd can gain capabilities from existing binaries and other script projects, becoming increasingly powerful.

---

The main reason I gave up TypeShell project was that the startup time became a problem. At that time, node 8 was mainstream, and node 10 had just become LTS. I remember that even using node 10, the startup time was poor compared to python/perl.

In addition to startup performance, size matters. I work on different servers and must carry a 20MB node/typescript zip package to run js script. This was acceptable to me, but I couldn't help thinking, what if the solution was only 5mb. Then I tried to rewrite it in golang, and got a version with a smaller startup time and size. Unfortunately, as I understood bash more deeply, I found that basic functions could be easily accomplished through bash and curl. When I was halfway through, I realized that bash was not available in some places. I challenge to rewrite it with posix shell and awk. After years of effort, x-cmd is almost ready now.

---

Friends, I'm not saying that tools like zx are not good. I do like to write some scripts using js/ts. I believe pythoners prefer https://xon.sh/ . Perl is interesting. Fish is friendly.

However, I believe posix-shell has its own advantages. The balance among size, code length, and expressiveness. I think the only possible competitors are tcl and perl, maybe lua. But none of the above is included by default in all server/container environments.

---

I wouldn't advise using posix-shell due to its numerous potential issues. I think people should write scripts using the language and library they are familiar with, and do it for fun. Friends of js/ts use zx/bun-sh/..., pythoners use xon.sh, etc.

Engineers can use x-cmd like `x .[py|mjs|lua|...]`. Then x-cmd will automatically help you download the script runtime, scripts, and install dependencies before running.

This is the future I have always wanted to achieve.

Post reply on HN