Python is such a mess, most likely the script you wrote won't work on a coworker's machine. Either it accidentally needs some global package installed, and then if course the needed version interfers with something else. Or the script only works for certain versions of python etc.

For most of our big scripts at work, I've actually resorted to just running them inside a docker container, mounting my current folder. So tired of trying to get my env to match someone else's.

>>Python is such a mess, most likely the script you wrote won't work on a coworker's machine. Either it accidentally needs some global package installed, and then if course the needed version interfers with something else. Or the script only works for certain versions of python etc.

So true. You have to be very careful when writing python, because cool language idioms that you use (or function calls), may not have been introduced in say for example Python 3.5. So when someone runs it with a different interpreter it will not work.

Writing python scripts that not-python-knowing people could use, is an art.

Instead, I work for a company who's core was written in bash and perl, and those scripts still work today after 15 years.

I would use Python much less often if it weren’t for Poetry [1], but with it I’ve never had a colleague fail to get a script running.

[1] https://python-poetry.org/

Have problems with poetry all the time. Upgrade minor version of python, suddenly there is no wheel available for some combination of platform+architecture. Forces you to build the stuff yourself, thus having to install a complete cpp build chain.

I haven’t come across this but I use only whatever versions of Python are provided by the [email protected] and/or [email protected] Homebrew packages and Debian testing or stable so am very likely not at the bleeding edge.

That or I don’t have interesting enough dependencies :)

It's definitely a pain not knowing if your python3 is 3.5, 3.6, or later. If you stick to using the older syntax and standard library, though, it's a fairly reliable replacement for bash. Though, in my situation the environments are pretty tightly controlled, so maybe I've got a biased set of experiences.

There are legitimate issues but in most cases I encountered, the complaints are of the kind: "it doesn't behave exactly like solution from another language that I happened to learn first and therefore Python sucks.

What is the dependency management solution for bash that it so much better than anything in Python?

Probably none. So the problem is really that so many brittle scripts get passed around, instead of either making it selfcontained on containerized.

I completely feel your pain, however check out poetry.

Package management and a virtual env manager in one.

It just blows my mind that this, and some of the other idiosyncracies of Python are not sorted out.

Python3 was a big stain because of those issues.

Python 4 could literally just be a platform shift to sort out paths, libraries, dependencies, documentation in order to try to solve all those problems.

It's just amazing how nutty things can be for tech we all depend on.

We would have never designed something that way on purpose.

Bash - as a non-expert I also feel is a bit wierd.

I almost what Computer Science God to come along and make a shell script, a clean light language like python/js, maybe something like Swift/Java, and then something like Rust but a bit easier - and they all feel a bit similar and integrate and the build tooling is fairly clean and the whole world can get along.

If you don’t feel comfortable writing shell scripts, or even for people who do :-), shellcheck especially when used as a vscode plugin will hold your hand and catch any potential problems with your shell script before it’s even run.

The problem is not me, the problem is Bash.

I do agree with your overall points but it’s worth noting that Go has been pretty stable in that regard. In fact backwards compatibility is one of the core missions and has lead to various design decisions that have left many wishing Go would break its compatibility promise. But I do agree it still wouldn’t compare against Bash’s multi-decade of consistency.

Why do you need Go on the system? Build a binary and install it… no need for Go on the target machine.

> Python and Go will probably change faster than Bash. So the maintenance cost of scripts in Python or Go will be higher.

This is something I'd like to see addressed by programming languages. Wouldn't it be nice if you could say "pythonversion 2.7" at the top of your program, and it would use that version of the language for the remainder of the file?

Doesn't something like pyenv handle the intent here though?

I don't think it can handle per-module versioning, but I could be wrong.

I never encounter machines without Python and never had issues porting Python scripts around since at least 15 years.

> So the maintenance cost of scripts in Python or Go will be higher

For Go, yes. For Python it's very rare for an old codebase to break unless you are talking about Python2/3

Why would anyone change Bash now?

Apple shipped an "old" version of bash due to licensing issues which means if you're relying on any bash 5 extensions you're SOL. Now that zsh is the default is Apple even shipping bash anymore? Things get even more fun if you've multiple versions of bash installed at once.

Yes, they still ship bash because 99.9% of shell scripts have bash in their shebang.

Backward compatibility is king.

It would make a superb April fool's if done correctly :)