Bash Ubiquity Trumps Python

With Windows on board, Python loses yet more ground

Update October 7, 2018:

I neglected to consider one very important use case (which I used a lot during my days at IBM): asynchronous network remote task scheduling. Back then we used Fabric. Well, Fabric 3 and Celery are clearly showing Python is the dominant “glue” language for systems management and compliance sorts of things that do not warrant a tool written in Go but are more involved than a shell script—particularly if they are multiple tasks that can be done concurrently. The fact that Python cannot make up its mind on concurrency (with no less than five variations, far from the “one best way” mantra) is largely irrelevant to the compliance engineer who quickly wants to right up a task that runs on everything and can use expect like interactions directly with remote command lines. No, in this area Python clearly dominates after having killed both Perl and Ruby in that same space.

While coding hundreds of end-point audit and remediation scripts in POSIX (Bourne) shell for IBM the dream of using improvements brought about by bash or even ksh for that matter was something I looked at longingly. Such things still required a shell that was 100% compatible with all previous and existing UNIX/Linux systems.

Those days are gone for most.

First, Linux has gained so much ground that it is now the default operating system for most web hosting, microservices, and Internet of Things devices—and Linux comes with bash (yes, I do know about ash on Debian by default now).

Then along comes Satya Nadella—the best thing that ever happened to Microsoft—and suddenly Windows comes with bash in addition to its own PowerShell. VSCode (also from Microsoft) requests that you download git-scm.org when you first use its built in interactive shell, which, by the way, takes Windows into a whole new class for developers because gone is the ancient cmd shell for serious development.

You could make the case that the bash command line and Linux-like terminal on Mac is what made Macbook Pros standard equipment for most developers (and still is in many circles).

The point is bash is everywhere. One was once required to say, “bash is everywhere—except Windows.” But the times, they are a changin’.

“What does any of this have to do with Python?” you ask.

For years all the incredibly powerful extensions to the POSIX shell syntax that bash brought were largely ignored. One could not be sure such things would run even on different versions of bash on different systems. This led, I believe, to an adoption of Python for such work. With Python you knew there would have to be a specific version of Python installed and therefore could reliably code to that version—sort of.

Python’s biggest failure to date has been the same thing that plagued Java and destroyed the dream of “write once, run anywhere.” You never knew which version of the interpreter you had.

This led to Python virtual environment insanity just to be sure you had, not only the interpreter you needed, but also all the dependencies that matched it. One can’t fault Python entirely for this since it is a flaw in any registry-based module system—and the reason Go is excelling having thumbed its nose at such things placing the responsibility firmly on the developers for dependency and promoting static linking so no interpreter is needed. But I digress.

Python won over Perl because of its explicit, simple nature and ability to do OOP (back when people were OOP obsessed). It also won as the best enterprise “glue” language because of it.

Here’s the thing.

Bash was still relatively new back then and not all UNIX systems in the enterprise were Linux-ish. This led to enterprise architects picking Python. Had those same architects been presented with current deployments and possibilities you would see a very serious architect considering bash instead. After all, bash can ship its interpreter much more reliably and enjoys standardization that Python does not. But most importantly…

Bash is already on most systems. Python is not.

That is huge.

Sure bash doesn’t have all the OOP that made Python popular. But people who want that level of complication and scale are not turning to Python anymore. They are overwhelmingly picking Go. These are just the facts. Systems development and DevOps is dominated by Go lang today. If that isn’t immediately obvious you simply have not been paying attention (uhmm, Docker, Kubernetes, etc.)

So where does Python stand as the “glue” language for ad hoc and automation?

It doesn’t.

Now that bash is everywhere there is literally no cost-effective argument not to use it over Python for such things, period.

Luckily (for Python) Python has deluded a significant majority of IT sheeple into thinking it is the only or best language for beginners and AI and data science. This is simply and objectively not the case. It might be the most commonly picked, but it certainly is not the best by any objective measure. (That is a topic for another post.)

And so, bash becomes a first-class, priority language here at SkilStak. Bring on those extensions! (Humm, ${#myvar} gives the length of the string?! Awesome!)