Python: The Language I Can't Quit (And Why You Shouldn't Either)

I spend a lot of time talking about Go — how fast it is, how clean the concurrency model is, how you get a single binary at the end. All true. I stand by it.

But Python is still the language I reach for first when I need to think about a problem.

Go is what I use when I know what I'm building. Python is what I use when I'm figuring out what to build. They serve different purposes, and pretending otherwise is dishonest.

Why Python Keeps Winning

The syntax is the obvious answer. Python reads like pseudocode that actually runs. You write a loop and it makes sense. You import a library and it works (usually). The barrier between "having an idea" and "seeing results" is lower than any other language I've used.

But the real reason Python dominates — especially in actuarial and quant work — is the ecosystem. It's not even close.

• NumPy and Pandas for numerical work. Handles data at scales that would make Excel cry.
• SciPy and scikit-learn for statistical modeling and machine learning.
• Matplotlib and Plotly for visualization that doesn't make you want to gouge your eyes out.
• TensorFlow and PyTorch when you need to go deeper.

There's no equivalent density of high-quality libraries in any other language. R comes closest, but the tooling is worse and the deployment story is a nightmare. Go has a small but high-quality ecosystem that covers most needs, but it doesn't have Pandas. And sometimes you just need Pandas.

The GIL Is Real, But It's Not a Dealbreaker

Everyone loves to hate on Python's Global Interpreter Lock. And sure, it's a real limitation. You can't use threads for CPU-bound work because only one thread runs at a time. For parallel number crunching, you need multiprocessing, which comes with its own headaches.

But here's the thing: NumPy bypasses the GIL. It's written in C and Fortran, and it doesn't play by Python's rules. For most actuarial and data science work, you're spending your time in NumPy operations anyway, so the GIL is mostly irrelevant.

The GIL matters when you're writing custom loops over millions of items. If that's your workload, use Go. If you're doing matrix operations, statistical modeling, or data wrangling, Python is fine.

What I Actually Use It For

Exploratory data analysis — Jupyter notebooks are still the best environment for poking at data and figuring out what's going on. I start there, get a feel for the data, then formalize the logic into proper modules.

Prototyping — When I'm testing a new pricing model or a trading strategy, I prototype in Python first. It's faster to iterate. Once the logic is solid, I might rewrite the performance-critical parts in Go.

Automation — Python's standard library is incredibly rich. File management (I built gniphyl for this), data processing, API wrappers — Python handles the glue code that connects all the pieces.

Plotting — Matplotlib and Plotly produce publication-quality charts with reasonable effort. R is better for statistical plots, but Python is good enough, and I don't have to switch languages to get it.

When NOT to Use It

I've learned this the hard way. Python is not a systems language. It's not for high-frequency trading, real-time processing, or anything that needs to run reliably for months without intervention. The deployment story is fragile — virtual environments, dependency conflicts, Python version mismatches. It's manageable, but it's never pleasant.

If you're building a production service that needs to handle load, or a simulation engine that processes millions of policies, or anything where performance and reliability are critical — reach for Go, Rust, or even Java before Python.

But for everything else? Python is fine. More than fine. It's the most productive language I know for the 80% of work that doesn't need C-level performance.

The Tooling Keeps Getting Better

The latest development that's worth paying attention to: uv. It's a Python package manager written in Rust, by the same team that built Ruff. It's 10-100x faster than pip, handles environments and dependencies with a single tool, and generates proper lockfiles.

No more 3 AM pip resolution errors. No more "I don't know what version of anything is installed." Uv fixes the worst part of the Python experience.

The Bottom Line

Python isn't going anywhere. It dominates data science, machine learning, and actuarial modeling for good reasons. The ecosystem is unmatched, the productivity is real, and the tooling is finally catching up to the language's ambitions.

I use Go for systems. I use Python for exploration. I use Excel only when someone pays me to. That balance has served me well, and I'd recommend something similar to anyone doing quantitative work.

Learn Python first. Then learn Go for when you need to ship. And leave VBA in the grave where it belongs.