Hacker News Reader

Comment by asa400 | Hacker News Reader

> I sometimes wonder why we don't see ruby used for shell stuff more often.

The reason we don't see Ruby used more for shell stuff is because Python won this particular war. It's already installed on basically every Linux distribution out there, and this simple fact outweighs all other language considerations for probably >95% of people who are writing shell scripts in something that isn't Bash.

Personally, I don't much like Python, and even though Ruby is not my favorite language either, I find it much better than Python for this kind of work. But I don't get to decide how Debian builds their infrastructure, so in the end, I tend to use Python.

View on HN

Yes, Python won the war, which is a pity. Linux distributions started getting bloated at the same time they switched to Python for everything. Yum hanging inexplicably and such things never occurred before.

The BSDs do not have this problem (yet!). I hope they stay sane and keep using Perl/sh.

Yum hangs not because of Python but because Fedora's RPM metadata is bloated compared to other distros so yum has to load and process much more data.

This is also the reason perl was used before python began to dominate. It was installed everywhere before python was installed everywhere.

this whole argument is silly. In my time on this site, I have seen someone suggest that every language is good for shell scripting including C.

Python and bash are used in the real world most often because convincing your sysadmin/infra/boss guy to install ruby for one script is a hard sell when you already have good-enough tools built into the system that don't add risk/complexity.

How hard is to install it though? That doesn't sound like a reason not to use it.

If a client has certified a specific Linux distro as an approved platform, that's what we use.

We can either deliver a single executable (Go) or a Python script, as python is preinstalled on their distro.

If we'd want to use Ruby, it'd be a huge hassle of re-certifying crap and bureauracy and approvals and in that time we'd have the Python solution already running.

Without a root account or inclusion in sudoers list, quite hard. There's millions of people that don't control the machines they work and spend most time with.

Significantly harder than doing nothing

Depends on you, your team, your target hardware/os, your project, and many other factors. Considering all of those things, the hurdle of installation might just be too large for it to be worth it.

It's not. This is a non-issue. Every web shop is writing bash to twiddle a build script on servers they also manage, which includes the ability to install any package they want.

How hard is it to install anything? That really isn't the point.

Seems like a lot below and around bring this as the main point for not using it. Which doesn't make sense to me.

Mitigating the risk of downloading a script from the internet and executing it -- even from a "trusted" website or package manager -- is absolutely a good reason not to use it.

Any decent distro has it. So you don't need to execute any random scripts, just install it or prepare the image with it for your OS install. That's it.

I don't really get this whole defaults being a blocker for tools choice.

And of course, it is impossible to install additional interpreters on the computer.

I never started using python, ruby or node because all of them were a pain to use for me - this was 7-8 years ago, so maybe it has changed a lot. But even 2-3 years ago I had lots of issues just running one python project. Module, not module, pip or not...

Way too confusing, compared to go for example. Or hell, even Java/Kotlin when you use an IDE and it autoconfigures most things.

> It's already installed on basically every Linux distribution out there,

PEP 668 pretty much negates this though. To do anything you need a python environment set up per script/project w/e

Iff you’re going beyond stdlib. Which lots of useful python programs don’t need to do.

Even if you don't want to limit yourself to the stdlib, you can still use a zipapp : https://docs.python.org/3/library/zipapp.html

You need to introduce a build and release process then to do this then which still detracts from it being simple or the selling point being it's already installed.

With cpan it's the same, you need to install deps somehow.

You don't need it if it's just a python script with stdlib, just like with raw perl.

Python ships with venv support. It’s not that difficult to bootstrap a venv before running your script, and that’s only if you actually need tooling other than stdlib, which you probably don’t.

It's definitely clunky and tedious to switch between every projects or scripts environment.

Idk why people are pretending there aren't tons of useful libraries out there. Like if you want to script anything with aws, use yaml

There are plenty of ways to have the venv automatically activate (and de-activate) when you enter/leave the directory for the project. direnv [0], mise [1], or various shell hooks.

There are useful libraries, I’m not saying there aren’t. I just dislike it when people include one as a dependency when they really didn’t need it.

[0]: https://github.com/direnv/direnv

[1]: https://github.com/jdx/mise

Reply on news.ycombinator.com