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.
Zx 3.0
101–110 of 169 posts
Re: Zx 3.0
#102As 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
Still doesn't let you easily get the output of the two commands, but a good start.
Re: Zx 3.0
#103I personally find Ruby's built-in shell features more ergonomic: `cat package.json | grep name` branch = `git branch --show-current` `dep deploy --branch=#{branch}` if $?.success? [ "sleep 1; echo 1", "sleep 2; echo 2", "sleep 3; echo 3", ].map { |cmd| Thread.new { %x(cmd) } }.each(&:join) name = 'foo bar' `mkdir /tmp/#{name}` if $?.success?
How do you do shell escaping of #{name} if it comes from user input?
It doesn't matter where input comes from. Input needs to be escaped for the context it's used in, period. Non-exploitable doesn't mean it's correct.
Re: Zx 3.0
#104As 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…
Imagine if instead of that, you could do:
foo, bar, []err := await getFoo(), getBar()
if len(err) > 0 {
return nil, nil, fmt.Errorf("Frobnication failed: %s", err)
}
return foo, bar, nil
Of course, JavaScript having exceptions as the main error-raising approach and `await` supporting them makes that a lot easier.Re: Zx 3.0
#105> 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
#106Earlier quoted context omitted.
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?
Since they started out owned by Google, you need permission to open source them.
But how much company support they have and how popular they are varies.
Re: Zx 3.0
#107 await $`dep deploy --branch=${branch}`
…
await $`mkdir /tmp/${name}`
Code like this[1] looks prone to shell injectionRe: Zx 3.0
#108I personally find Ruby's built-in shell features more ergonomic: `cat package.json | grep name` branch = `git branch --show-current` `dep deploy --branch=#{branch}` if $?.success? [ "sleep 1; echo 1", "sleep 2; echo 2", "sleep 3; echo 3", ].map { |cmd| Thread.new { %x(cmd) } }.each(&:join) name = 'foo bar' `mkdir /tmp/#{name}` if $?.success?
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…
https://ilya-sher.org/2017/01/28/ngs-unique-features-exit-co...
Re: Zx 3.0
#109await $`dep deploy --branch=${branch}` … await $`mkdir /tmp/${name}` Code like this[1] looks prone to shell injection [1] https://github.com/google/zx
They could also be parsing out the first word as the command and not using shell execution at all.
Re: Zx 3.0
#110> 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-...