Live data from Hacker News

Zx 3.0

github.com

91–100 of 169 posts

Re: Zx 3.0

#91

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…

> Even Go, that prides itself on the good support for parallelism, fails once you actually want go get results back.

It's doable if you're willing to build a very thin abstraction over whatever you're trying to parallelize keeping in mind all possible edgecases [1] and how you'd like to handle them.

A generic `run N things in parallel and collect their results` function would be nice, but would probably end up being quite unwieldy in comparison to just writing out a purpose-specific function for what you exactly need.

[1] - Error handling, timeouts/cancellation, maximum amount of processes running in parallel, wait-for-full-join vs. returning results as they appear, introspection of currently running subordinates, subordinate output streaming/buffering/logging, ... A lot of things to consider when you're trying to build something universal, but that are easy to solve/ignore when you're building something purpose-specific with known constraints.

Re: Zx 3.0

#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-...

Re: Zx 3.0

#93

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…

Awaiting on every line is hardly parallelism.

Re: Zx 3.0

#94
post #8
post #3

Earlier quoted context omitted.

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)

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.

Re: Zx 3.0

#95
post #38
post #28

Earlier quoted context omitted.

The copyright of the thing Googlers build on their oswn time are usually owned by Google and so it ends up on the Google org if they want it on GitHub. They usually have a disclaimer like "this is not a official Google product..."

This isn't correct: if a Googler writes some code from scratch, which is unrelated to their work, on their personal time, and using their personal laptop... then it's definitely not owned by Google. There could be gray areas where code ownership could be disputed, but in general your employer owns only the intellectual property it paid for. Source: I'm a Googler (until next month).

OK. So the things under google GitHub organization are personal projects for which googlers didn't bother to get the permission?

Re: Zx 3.0

#96
post #8

Earlier quoted context omitted.

how is the name unfortunate? from the site: > Plumbum (Latin for lead, which was used to create pipes back in the day)

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

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.

Re: Zx 3.0

#97

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.

I'm less likely to have Perl installed than Python on Windows, where I sometimes want my scripts to run as well.

It's also unlikely you have Python installed on Windows though, and there's a non-insignificant change that's an old or random version (probably even Python 2). You can't rely on anything on Windows, so you're definitely going to also install a runtime from Chocolatey or similar.

Re: Zx 3.0

#98

Earlier quoted context omitted.

> 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.

I've seen instances of some Unix systems not having Perl installed, but that's very rare. Basically everything directly or indirectly depends on Perl, so you really have to run your scripts on a minimal install of RHEL of FreeBSD with 0 ports in order to get into such a situation.

Re: Zx 3.0

#99

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 images and you have a new level of 'what may or may not be there'. Ah but you may say 'oh just use tech XYZ' that may or may not have the exact same issue as using python in its place. So either 'deal with it' and install what is needed and keep it up to date. Or 'play the LCD game' you use only the bare min and hope you can build something useful enough in bash when another lang may be more appropriate.

Re: Zx 3.0

#100

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…

Take a look at GNU Parallel. It’s magnificent.
Post reply on HN