The 'Second Best' Language That Won Everything: How a Christmas Hobby Project Became the World's Most Popular Programming Language

It was Christmas 1989 in Amsterdam. Guido van Rossum, a programmer at the Centrum Wiskunde & Informatica (CWI), was staring at another week of holiday downtime with nothing to do. His office was closed. His colleagues were away. And he was bored.

So he did what any restless programmer would do: he started building a new programming language.

Not because the world needed one. Not because he had venture funding or a grand vision to change computing. He just wanted something that was fun to use — a language where the code looked like what it did, where you didn't need a PhD to read it, and where you definitely didn't have to write Perl.

"I wanted to create a language that was easy to learn and use," van Rossum later said. "Something that would appeal to Unix/C hackers but also be accessible to people who weren't professional programmers."

He named it after Monty Python's Flying Circus. Because why not?

Thirty-five years later, Python is the most popular programming language on Earth. It powers Google's search infrastructure, Netflix's recommendation engine, Instagram's backend, ChatGPT's API, NASA's Mars rovers, and probably half the Jupyter notebooks running in corporate data science departments right now.

Here's the twist: Python is objectively worse at almost everything than specialized alternatives. Go is faster. Rust is safer. JavaScript owns the browser. C++ dominates gaming. Java runs enterprise.

But Python won anyway.

This is the story of how the "second best" language became the first choice for everything — and why that might actually be its greatest strength.

The Controversial Decision That Changed Everything

Van Rossum made one decision in those early weeks that seemed insane to veteran programmers: he made whitespace significant.

In C, Java, JavaScript — hell, almost every language in 1989 — you used curly braces to define code blocks:

if (x > 0) {
    doSomething();
    doSomethingElse();
}

Python said: screw the braces. Use indentation:

if x > 0:
    do_something()
    do_something_else()

Programmers hated it. "What if my editor screws up the spacing?" "How do I see where blocks end?" "This is whitespace fascism!"

But van Rossum had noticed something: every programmer already indented their code for readability. The braces were redundant ceremony. Why not enforce what everyone was doing anyway — and make the code impossible to misread?

It was genius. Python code became readable. Not "readable for a programming language" — actually readable, like English. A manager could skim it. A scientist could understand it. A 12-year-old could learn it.

Readability wasn't a nice-to-have. It was the whole point.

Batteries Included: The Standard Library That Launched a Thousand Scripts

The second superpower: Python shipped with everything.

Want to parse JSON? import json. Need HTTP requests? import urllib. File I/O? Regular expressions? Email? SQLite? CSV parsing? All there, built-in, no installation required.

Van Rossum called it "batteries included" — the idea that Python should come ready to solve real problems out of the box. No hunting for third-party libraries. No dependency hell (well, not yet). Just import and go.

This was revolutionary in the 1990s. Perl required CPAN modules for everything. C required linking external libraries. Java's standard library was verbose and enterprise-focused.

Python's stdlib was pragmatic. It wasn't the fastest implementation or the most theoretically pure. It was the one that let you write a web scraper, automate server deployments, or process CSV files in 20 lines of code on a Sunday afternoon.

The language optimized for getting shit done.

The Ecosystem Moat: How Python Accidentally Conquered Every Domain

But here's where the story gets interesting. Python didn't conquer the world through language features. It conquered through ecosystem lock-in.

Web development? Django shipped in 2005 with "the web framework for perfectionists with deadlines." Instagram built their entire backend on it and scaled to billions of users. Flask followed as the lightweight alternative. Then FastAPI came along in 2018 with async support and automatic API documentation — and suddenly Python could build REST APIs faster than Node.js.

Data science? NumPy (1995) gave Python the ability to manipulate arrays with C-level performance. Pandas (2008) made data analysis trivial. Jupyter notebooks (2014) turned Python into an interactive playground for exploration. Suddenly, every data scientist, analyst, and researcher was writing Python — not because the language was fast, but because the ecosystem was unbeatable.

AI and Machine Learning? This is where Python became unstoppable. TensorFlow, PyTorch, scikit-learn, Hugging Face Transformers — every major ML framework chose Python as its primary interface. Why? Because researchers don't want to fight with C++ compilers and memory management. They want to iterate fast, visualize results, and share notebooks.

NumPy's secret weapon: it's Python syntax on top of C/Fortran performance. You write array1 + array2 in readable Python, and under the hood, optimized C code does the heavy lifting. You get developer ergonomics and speed.

DevOps? Ansible, Fabric, SaltStack — all Python. SREs loved it because they could read each other's automation scripts without a Rosetta Stone.

Finance? Bloomberg, Goldman Sachs, JPMorgan — Python everywhere. Quant researchers could prototype trading strategies in Jupyter, then hand them to engineers to optimize.

Python became the glue language — the thing that connected everything else. And once the ecosystem reached critical mass, it became self-reinforcing. New libraries begat more users. More users begat more libraries.

The Honest Cons: Why Python Is Also Kinda Terrible

Let's talk about why Python drives engineers crazy.

The GIL (Global Interpreter Lock): Python's CPython interpreter has a lock that prevents true multi-threaded parallelism. You can spawn 1000 threads, but only one executes Python bytecode at a time. For CPU-bound work, this is a disaster. The workarounds? multiprocessing (spawn separate processes — clunky), or asyncio (event-loop concurrency — not real parallelism). Go and Rust developers laugh at this.

Speed: Python is slow. 100x slower than C/Rust for CPU-intensive tasks. A tight loop that runs in 10ms in C takes 1000ms in Python. Sure, you can drop into C extensions (NumPy, Cython), but then you're not really writing Python anymore.

Dynamic Typing: No compile-time type checking means bugs hide until runtime. You deploy to production and then discover you passed a string where the function expected an integer. TypeScript and Go catch this at build time. Python says "runtime YOLO."

Type hints (introduced in Python 3.5) help — you can write def process(data: list[int]) -> str: — but they're optional and not enforced. Tools like mypy exist, but adoption is spotty.

Dependency Hell: Oh boy. pip, virtualenv, pipenv, conda, poetry, pyenv — pick your poison. Want to install packages? Hope you're in the right virtual environment. Want reproducible builds? Good luck with version conflicts. JavaScript's npm/yarn is messy, but at least it's one mess. Python has five competing standards.

Packaging is still broken in 2025. Ask any data scientist who's tried to pip install tensorflow on a Mac with an M-series chip.

The Honest Take: Python is the "second best" language for almost everything. It's slower than C/Rust, less safe than Rust/Go, less elegant than Haskell, worse at concurrency than Go, worse at frontend than JavaScript.

But it's the first choice because developer velocity and ecosystem matter more than raw performance for 90% of problems. Most software isn't fighting for nanoseconds. It's wrangling APIs, transforming data, orchestrating infrastructure, training models, building CRUD apps. Python lets you do all of that without fighting the language.

The Future: Killing the GIL and Competing With Yourself

PEP 703 (GIL Removal): In October 2023, the Python Steering Council approved a plan to make the GIL optional. The goal: true multi-threaded parallelism by Python 3.13 (late 2024) or 3.14 (2025). This is massive. If Python can do real parallelism without forking processes, it closes one of its biggest weaknesses.

Faster CPython Initiative: Since Python 3.11 (2022), the core team has been obsessed with speed. Python 3.11 was 25% faster than 3.10. Python 3.12 brought another 5-10%. Python 3.13 is targeting another 20%. The language is getting faster — not C-level fast, but fast enough to matter.

Mojo: Here's the wildcard. Mojo is a new language from Chris Lattner (the guy who built Swift and LLVM) designed as a "superset of Python" with C/Rust-level performance. It's Python syntax with static typing, compile-time optimization, and CUDA support. Mojo could do to Python what TypeScript did to JavaScript — same syntax, better guarantees.

If Mojo takes off, Python might end up competing with itself for AI workloads.

The Legacy: Why 'Good Enough' Beats 'Perfect'

Guido van Rossum didn't set out to build the fastest language, or the safest, or the most elegant. He wanted something fun. Something readable. Something that didn't make you want to throw your laptop out the window.

Thirty-five years later, Python runs:

• The backend of Instagram (2 billion users)
• Google's internal tools
• Netflix's Chaos Monkey
• Dropbox's sync engine
• NASA's James Webb Space Telescope pipelines
• Every major AI model's training and inference code

It's the language kids learn in school, researchers use in labs, and engineers deploy in production.

Is it the best tool for any single job? Rarely.

Is it the first tool people reach for? Almost always.

Because in the real world, "good enough, fast to write, easy to read, and has a library for that" beats "theoretically optimal" every single time.

The 'second best' language won because being second best at everything is better than being the best at one thing.

And that's the most Pythonic lesson of all.