Why I Still Write Bash Scripts in 2026

The year is 2026. We have AI coding assistants. TypeScript dominates the stack. Rust evangelists control the discourse. Yet this morning I wrote a 40-line Bash script to orchestrate our deployment pipeline—and it shipped faster, ran more reliably, and will outlast every framework released this quarter.

Every few years, someone on Hacker News declares Bash obsolete. "Use Python," they say. "Use Node." "Real engineers use Rust." Meanwhile, literally every CI/CD system, Docker container, Kubernetes init script, and production deployment I've seen in 20 years still depends on shell scripts.

Bash isn't winning because it's elegant. It's winning because it's everywhere—and that ubiquity is the ultimate moat.

The Boring Technology Theorem

Here's the pattern: exciting technologies get the blog posts. Boring technologies run production.

When I started at Link11 in the early 2000s, people were hyping Ruby on Rails as the future of backend development. Today? Most high-traffic infrastructure still runs C, Python, and shell scripts. Rails exists, sure—but it's not running the kernel, the container runtime, or the deploy pipeline.

Bash has survived because it operates at the integration layer—the place where different systems need to talk to each other with minimal dependencies. You can't assume Python is installed. You can't assume npm works. But you can assume /bin/sh exists.

That assumption is worth more than any language feature.

Why Bash Still Dominates Ops

1. Zero dependency hell. Your 10-line Bash script works on Ubuntu 18.04, Alpine Linux, and your colleague's crusty MacBook without a single pip install or version mismatch.

2. Battle-tested ecosystem. grep, awk, sed, curl, jq—these tools have been refined for decades. They do one thing well, compose cleanly, and fail predictably.

3. Minimal surface area. A Bash script that works today will work in 10 years. Try that with any JavaScript framework.

4. Readable by everyone. Junior devs can read shell scripts. Senior SREs can debug them at 3am. You don't need to explain import paths or async/await semantics—just pipes and exit codes.

5. The ultimate glue code. Need to call an API, parse JSON, check a file, restart a service, and send a Slack notification? That's 15 lines of Bash. In Python? You're importing libraries, handling exceptions, managing virtual environments.

When Bash Is the Wrong Tool

I'm not a zealot. Bash has sharp edges, and knowing when not to use it matters just as much.

Don't use Bash for:

• Complex business logic. If you're writing nested conditionals with substring matching and arithmetic, stop. Use a real language.
• Anything over ~200 lines. Shell scripts don't scale to large codebases. Refactor into Python, Go, or Rust.
• Parsing complex data structures. JSON and YAML are doable (jq is magic), but anything beyond that and you're fighting the language.
• Cross-platform Windows support. PowerShell exists, but if you need portability across OSes, Python wins.

The heuristic: if you're thinking "this feels awkward in Bash," it probably is. Trust your instincts and switch languages.

The Compound Effect of Boring Choices

At Link11, we've been running shell-scripted deploy pipelines for nearly 20 years. We've upgraded Python twice. We've migrated databases. We've rewritten services in Go. The shell scripts? Still running.

That stability has compounding returns:

• Onboarding is faster (everyone already knows Bash basics)
• Maintenance is cheaper (fewer breaking changes, less rewrite churn)
• Debugging is simpler (less abstraction, clearer failure modes)
• Portability is free (works on every *nix system without installation)

Boring technology doesn't give you the dopamine hit of learning a hot new framework. But it gives you something better: time back.

Embrace the Boring

The infrastructure that powers your company—CI/CD, container orchestration, system init, cron jobs—probably runs on shell scripts. And in 2030, 2035, 2040, it still will.

Not because Bash is the best language. But because it's the most available language—and in infrastructure, availability beats elegance every time.

So yeah, I still write Bash in 2026. And unless someone invents a better universal glue, I'll be writing it in 2036 too.

Boring wins. Every time.

---