Hacker News Reader

Comment by jfkebwjsbx | Hacker News Reader

For small scripts there are many languages out there which are better, with a proper standard library and pre-installed runtimes in virtually every machine.

Why would someone want to use a new language and a new runtime in production scripts is beyond my understanding.

Just write Python for those. Even Perl, awk or sh would be better options, and that is saying something...

View on HN

This is a bit like saying "why would someone take a ferrari to the corner store, a honda sedan works just fine". The implementation of the task at hand is without consequence, their boss just wants X to happen even if it gets done by hand. I love these opportunities because I can use a language that I'm not getting paid to write for the 99% of of my day job. Coincidentally this happens to be python for me but i'll defend parent's right to do it in brainfuck if it makes them smile :)

Well I can think of few. For one, if you are writing a script with external dependencies, it's more work than deno to distribute them.

For python, you would need pip. Can you install any script from arbitrary urls using pip?

I am not sure but I don't think you can. You also have to declare your deps for pip to figure out.

With deno, it's just deno run -A url to script since dependencies are declared in the code with their respective url or file location.

The whole point of Python is that you don't need external dependencies for "small tasks and scripts".

A production "script" requiring downloads of third-party code from external servers is already a red flag, by the way.

You can setup your own mirrors which don't update without audits. Any competent company would do.

And I wasn't implying that production scripts shouldn't be self contained. Just placing my 2 cents on why.

How is maintaining mirrors of third-party code any easier, reliable, secure or maintainable than just running Python?

Mind you, your Python runtime has been vetted by the Python Foundation, your upstream vendor and your company; is used by many other companies and does not require any network connections to run.

One could extend that logic to argue that all package managers are red flags: after all, you're downloading third-party code from external servers; you just happen to be doing it ahead of time, rather than at runtime.

In principle, there's no reason why the same supply-chain security mitigations npm and other package managers / repositories have put in place could not also be applied in this case: you just apply them at download time, same as before, except now it might result in a runtime error instead of an npm install failure. (No idea if deno does this in its current state, tbh.)

Agree, however, that blindly executing third-party code without somehow vetting it is a security risk.

Also, re: Python - there's a reason why libraries like requests exist; while the Python Standard Library is pretty comprehensive, the APIs it exposes are not always the most intuitive. You might be surprised at how often people pull in helper libraries to work around some of its warts - now, one could argue that maybe they shouldn't do that and should just know the built-in modules better, just as one could argue that functionality is useless unless combined with usability.

Package managers are not red flags, the packages, its vendors and procedures behind those are.

When you download a software update for your kernel you are trusting the Linux Foundation and your upstream vendor. They are supposed to have proper processes in place, they sign the binaries and may even have a support contract with you.

When you put a random URL as a dependency, you are just trusting some random person over the Internet not to screw it up.

Re: Python libraries. The topic of this thread was about "small scripts and tasks". The point of Python and its "batteries included" is that you don’t need external libraries to accomplish common tasks. It is a mistake to use external helper libraries in your scripts (not apps).

> Can you install any script from arbitrary urls using pip?

You don't need to. Download any module or packgage, put it next to your code, and you can import it. There is nothing to do. There is not even need for metadata.

But yes, pip can install packages from arbitrary URLS, including git repos, if they contains the right metadata.

What's more, with something like shiv (https://github.com/linkedin/shiv), you can actually bundle those dependancies into one zipapp (an official python feature, see https://docs.python.org/fr/3/library/zipapp.html), which is basically a zip containing your entire project that you can just execute like if it were one py file.

Go is my tool of choice for scripting now. Compiles fast and has an extensive standard library. I've tried using node in the past but all of the async handling turned me off. I prefer go's way of implementing concurrency with go routines.

Go isn’t scripting, it is compiled, which defeats the purpose.

Why does it being compiled defeat the purpose?

The point of scripts is to easily automate tasks without the need for a heavy infrastructure behind them in the target.

If you have to install/run a pipeline every time you modify them (like C or Rust or Go or TypeScript), or you need to sort out distribution (if you use binaries compiled in another machine), or it takes a long time to compile & run (like Rust or C++), or you need to install a heavy runtime (like a JVM or .NET or v8), it defeats the purpose.

Go can `go run script.go` without more ceremony than that. But there are other tradeoffs:

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SysadminGo...

That compiles and then runs the resulting binary, so you still need the Go infrastructure and the latency.

Go is without doubt a better candidate for scripting than things like Rust or C++, but it cannot compete with the ubiquitous and featureful Python or built-in Unix tools (even more ubiquitous, but less featureful and quite dated).

To be clear, you need the infrastructure the first time you run it. If you run it _more_ than once, it will both start and execute faster than python.

> Go infrastructure Install go. Just Go

> latency Impercetible

I've written plenty of bash and python. Go is just better for me, if for no other reason, than the entire SDK is in my head as is the language

`go run` is quite comparable to `deno run` and in fact inspired a great many of its details. Deno's standard library is literally built as a copy of Go's standard library. They work the same way in many respects, and with Go's type inference and (effectively) duck typed interfaces... If you are familiar with Go it is probably a more suitable scripting environment than most other languages for... scripting tasks.

Python 2 or 3?

whichever one is on your computer

Sounds like that directly invalidates the use case of small portable scripts.

not really. its perfectly easy to write scripts that work with py2 and 3

Both work.

1) Your distribution vendor most likely supports both and allows you to install both at the same time.

2) Your company has probably a policy for that.

3) Small Python scripts are trivial to make compatible with both major versions.

4) Python 2 is deprecated but supported. Just write Python 3 for new code.

Python 2 was EOL this year. Short answer should be just "Python 3" by now.

Reply on news.ycombinator.com