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

81–90 of 169 posts

Re: Zx 3.0

#81

Post by geofft »

travelbuffoon wrote: post #62
sneak wrote: post #51

Earlier quoted context omitted.

There is very little code that a Googler could write that is unrelated to their employer’s business. You’re almost certainly going to need an explicit carve-out, as other Googlers in the thread have pointed out.

There’s a difference between: unrelated to your job, and unrelated to the business as a whole. In some locations, employers can’t claim copyright on works unrelated to your current role.

In many locations they can. I paid my own lawyers to review a Google NYC job offer and they said, yes, Google can enforce this clause.

(Obviously this is not legal advice, talk to your own layers, etc.)

Re: Zx 3.0

#82

Post by miohtama »

IshKebab wrote: post #79
tcbasche wrote: post #18

Earlier quoted context omitted.

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.

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…

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

Re: Zx 3.0

#84

Post by TeMPOraL »

zeroxfe wrote: post #77
TeMPOraL wrote: post #35

Earlier quoted context omitted.

Which makes no sense if the developers are the users... But in the spirit of "there are only two business models - bundling and unbundling", I guess there are only two marketing tricks: use an old term for a new thing, and introduce a new term for an old thing...

Or more charitably, while the UX/DX distinction isn't very meaningful for this project, there are lots of products (e.g., payments) that target both (non-developer) end users and developers. It helps to be able to separate the personas.

I don't think this holds. As the rule goes, there are only three cardinal numbers: zero, one, many. What are the chances you product has only two meaningful personas - "users" and "developers"?

Take that payment system. People who buy things are obviously users, people who write CMS plugins for that system are obviously developers. But what about, say, analysts studying reports from that system? Accountants making sure the money flows where it should? Sysadmins keeping the backend components running? These are all users too.

Where UX makes sense as a broad concept, giving a separate acronym to one small subset of potential users... doesn't make sense.

Re: Zx 3.0

#85

Post by thatwasunusual »

tyingq wrote: post #67

I suppose it's easy to poke fun at combining the "best" of shell scripting and JS. But, the examples of using await() with child processes and pipes are pretty nice, and less verbose than the Perl or Python equivalents. It does seem well designed for anything where you're orchestrating parallel runs of commands.

For Perl, there is now Future::AsyncAwait.[0] Mojolicius has already adopted it, so things are moving forward at the speed of the magnetic poles shift. :)

[0] https://metacpan.org/pod/Future::AsyncAwait

Re: Zx 3.0

#86

Post by thatwasunusual »

qalmakka wrote: post #36
cfeliped wrote: post #33

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…

That's why Perl is my go-to choice for glue scripts. It's almost always installed by default, it has stayed consistent for decades without any breaking changes, its regex support is by far the best around, and its almost as good as the shell at gluing commands together.

> That's why Perl is my go-to choice for glue scripts. It's almost always installed by default

My first thought was related to this as well: Perl is _always_ installed, and based on Python's popularity (compared to Perl, at least), I'd assume that Python also was installed by default?

That's an honest question, btw: I use Perl quite a lot, Python not so much (at all). :)

Re: Zx 3.0

#87

Post by Too »

mikevm wrote: post #16

Ugh, typing `await` for every command is terrible. JavaScript's async-by-default model is clearly not a good fit for this use case.

I think the idea is that the majority of the script will be written in pure JS, with only occasional calls out to subprocesses, so “every command” is far from every line.

You frequently see the same mental mismatch when shell-scripters try to use Python, and complain how hard it is to pipe with POpen, instead of using the built in string processing features.

Re: Zx 3.0

#88

Post by another-dave »

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 a LTS version I'd take a look at that stage.

To be honest though I like doing things in bash. You can get pretty far & it's 100% portable. If something's too complicated for bash it's probably time it's not just a simple CLI script anymore, in my experience.

Re: Zx 3.0

#89

Post by cfeliped »

thatwasunusual wrote: post #86
qalmakka wrote: post #36

Earlier quoted context omitted.

That's why Perl is my go-to choice for glue scripts. It's almost always installed by default, it has stayed consistent for decades without any breaking changes, its regex support is by far the best around, and its almost as good as the shell at gluing commands together.

> That's why Perl is my go-to choice for glue scripts. It's almost always installed by default My first thought was related to this as well: Perl is _always_ installed, and based on Python's popularity (compared to Perl, at least), I'd assume that Python also was installed by default? That's an honest question, btw: I use Perl quite a lot, Python not so much (at all). :)

Assuming Python or Perl are installed by default in any server is an invite to a world of pain. At least that's my anecdotal experience.

Re: Zx 3.0

#90

Post by rurban »

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…

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
Post reply on HN