31–40 of 169 posts
Ugh, typing `await` for every command is terrible. JavaScript's async-by-default model is clearly not a good fit for this use case.
The author of this library has chosen to make the "$" function they provide async; this isn't a JS design feature or limitation, it's just the lib author's choice.
And here is the same thing in Deno: https://gist.github.com/zandaqo/93004fb265146a95aadb28ec851a...
Here is a more full fleded version.
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 heterogeneous environments with (possibly) network and security barriers. Moreover, if you are using containers, installing Python will make images unecessarily large.
Granted, I'm not a JS person, but I imagine one will have the same issues.
Even though bash has its shortcomings, I really appreciate how low maintenance it is as long as you keep scripts small and sane.
Earlier quoted context omitted.
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.
While I agree that Node's ecosystem is not the best, it's what we have in the frontend world. If you're working on a Node-based service or React app, you already have to deal with Node and its package ecosystem. Adding a couple of extra MB (or even KB, depending on package reuse) on top of your existing chain of dependencies is a tiny con to the huge benefit of not having to do logic in Bash :)
Earlier quoted context omitted.
Oh man, I'm getting too old for this shit...
It's like UX but for developers...
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...
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…
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…
I'm having a hard time believing that Google uses this much internally. Is github.com/google just a place where Googlers can put personal projects to get additional exposure?
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..."
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).
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…
Still, zx isn't as nice as Ruby, which has backticks for calling shell as part of the language. So, you don't have to have a separate package installed, just the ruby runtine.
But Perl is even better! Just like Ruby, it comes with backtick shell execution build-in, but unlike Ruby Perl is ubiquitous and is pretty strict about backward compatibility. So, your scripts will just run on all machines you have, no matter what distro you use and how old the machine is (within reason).
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).
Not in the “haha, yes of course”, in the “I’ve spoken to HR and have it writing” kind of way.
I’ve heard this is not true from others, it is simply true in certain geographical regions where local laws override the contract you signed.