Ok, but why do I still use Stata?

Let’s get this out of the way immediately: I don’t like Stata. I have said this out loud, in actual meetings, more than once (sorry to anyone who was there). If you ask me what I would pick for a green field project, panel data, survey weights, whatever, my answer is R, every single time. And yet, here I am, several years into my career, and Stata keeps showing up. In my resume, in shared do-files from partner organizations, in “quick, can you just check this regression” Slack messages. So today, instead of pretending it doesn’t exist, I decided to sit down and actually write out why it refuses to leave my professional life, pros, cons, and everything in between.

Before we get into it, a quick note for my dear three readers who have never opened Stata: it is a statistical software package that has been the default choice in economics, public health, and policy research for decades. It sits somewhere between a programming language and a very opinionated calculator, you type a command, it runs it, and it spits back a regression table that looks eerily similar no matter who ran it. That last part sounds boring, but it turns out to be a big deal, and we will get to why.

The good, the reliable, the “why does everyone still use this”

It is basically the native language of applied economics and policy

If you work anywhere near development economics, public health research, or government adjacent policy analysis (hi, that’s me), Stata is not really optional, it is the language everyone around you already speaks. The World Bank’s DIME Analytics team has flagged Stata as the one notable holdout among proprietary software in a field that otherwise loves open source, precisely because it never lost its grip on development economics and econometrics. And it is not just a vibe, a Stata blog post breaking down American Economic Association data found that Stata shows up in roughly three out of every four data and code supplements submitted to AEA journals since the policy started. If you are trying to get hired in applied econ or policy research, job postings still ask for it constantly, especially anything involving panel data or replicating existing literature.

It handles panel and survey data like it was built for exactly that (because it was)

This one I will give Stata, genuinely, no sarcasm. Once you xtset your panel data by unit and time, every estimator downstream just knows what to do with it. Same with svyset for complex survey designs, you declare your strata, your clusters, your weights, once, and Stata quietly carries that design through every estimation command you throw at it afterwards. I do a lot of work with survey and index data at my job, and not having to re-specify weights and clusters every single time is a small mercy I did not appreciate until I had to do the equivalent by hand somewhere else.

xtset country year
xtreg outcome_index rule_of_law_score, fe vce(cluster country)

svyset psu [pweight = wt], strata(strata) fpc(fpc)
svy: mean rule_of_law_score

The one-click do-file, at least in theory

Reproducibility in Stata is a genuinely split experience. For a single, isolated line of code, it comes almost for free, StataCorp keeps folding new functionality straight into base Stata instead of spinning it off into third party packages, and pinning version 15 (or whichever release you are targeting) at the top of a do-file mostly lets you sidestep the dependency hell you can run into chasing exact package versions in R, Python, or Julia. That part I will genuinely give it.

What I will not give it is the idea that the Stata community, as a whole, has internalized good software engineering habits. Most of the do-files I have inherited over the years were written for a one shot run, someone’s dissertation chapter, a single deliverable, not for a stranger to pick up three years later. Documentation, modular functions, anything resembling scalable or maintainable code, is still the exception rather than the norm. That is exactly why things like DIME’s reproducibility guidelines and Julian Reif’s Stata coding guide exist in the first place, they are trying to impose a discipline the community has not developed on its own. And because the American Economic Association and the Econometric Society now require replication packages before publishing empirical work, that discipline is at least becoming less optional.

The syntax does not fight you

There is a reason people describe Stata as “easy” even when they mean it as an insult. regress y x gives you a regression, reg y x, robust gives you the same regression with robust standard errors. You do not need to load six libraries or remember which function belongs to which package, the commands are already there, already documented, already used by thousands of people before you, which means when something breaks, someone has already asked about it on Statalist.

The bad, the annoying, the “why I still complain about it”

It costs actual money, and not a small amount

Here is the part that will never stop bothering me as someone who came up through R. Stata is not free, and it is not cheap either. A single business user license for Stata/SE currently starts around 925 dollars a year, climbing past 1400 dollars a year for the higher core counts of Stata/MP. You can also buy perpetual licenses, which do not expire, but even those come with an annual maintenance fee if you want to keep getting updates. Also, I’m not sure if these are still available for purchase.

In practice though, if you work anywhere near a university, an NGO, a think tank, a multilateral, or basically any research oriented organization, someone else is almost certainly already paying for your seat, I honestly cannot remember the last time I had to buy a license myself. The actual problem falls on people outside of that world, a freelance analyst, a student between institutions, anyone who wants to keep their Stata skills sharp without an organization backing them, that is where the price tag actually bites. Meanwhile R and Python sit there, free, for absolutely everyone, no institutional affiliation required.

It used to be embarrassingly bad at multitasking

Honestly, this was my single biggest issue with Stata, right up there with it being proprietary in the first place. For most of its life, Stata could only hold one dataset in memory at a time. One. If you needed to peek at a second dataset, you had to preserve, do your thing, and restore, or merge everything together and hope your memory did not explode. Stata 16 finally introduced frames in 2019, letting you hold multiple datasets in memory and reference them by name, and for me personally, that was a genuine game changer, it is the closest Stata has ever felt to working the way R or Python already did. There is a whole guide dedicated to it if you want to nerd out. The catch is that, in practice, most Stata users I run into still have not picked frames up, old habits with preserve and restore die hard, so the fix exists, but the community has been slow to actually adopt it.

It is not really a general purpose language, and it does not pretend otherwise

Try to scrape a website, hit an API, or train anything resembling a machine learning model natively in Stata, and you will feel the walls close in fast. StataCorp knows this, which is why they built PyStata, letting you call Python libraries like NumPy or scikit-learn from inside Stata itself. Which is a fine solution, except it is also a quiet admission that Stata alone is not enough anymore for a lot of modern data work. I do not mind reaching for another tool when I need one, that is normal, but it does mean Stata rarely gets to be the only thing in your stack, just the thing everyone insists stays in it.

The ecosystem feels small next to what you get elsewhere

Stata has user written packages too, hosted mostly through SSC, and some of them are genuinely excellent. But it is nowhere close to the size or speed of CRAN or PyPI, where entire subfields spin up new tools every week. Ask around on Statalist and you will find plenty of long time users admitting that finding a well documented, well maintained Stata package for a niche task is harder than it should be, mostly because there are simply fewer people building them.

I have no hard data to back this up, this is purely a pattern I keep noticing, but my honest impression is that younger developers doing genuinely new methodological work reach for R or Python first, and Stata gets it later, either folded into a future base release or ported over as an SSC package by someone else entirely. Take that with a grain of salt, it is a vibe, not a citation.

Most of us now ask AI instead of digging through Statalist or Stack Overflow, but that convenience isn’t equal across languages, a 2026 study published in Health Economics Review found ChatGPT was noticeably more error-prone writing Stata code than Python or R for the same causal inference tasks. The likely reason isn’t Stata’s syntax, it’s training data, there’s just far less Stata code out in the open for a model to learn from. So the old disadvantage didn’t go away, it just moved into the chat window.

Worth flagging though, that comparison was run on ChatGPT-4.0 Pro, which already feels like a snapshot from a different era. Newer models are a different beast entirely, look at what Fable 5 or Opus 5 can do compared to that generation, and coding agents like Claude Code hold far more context about an actual codebase than a single chat prompt ever could. So I would not take that table as gospel for where things stand today. That said, and I have zero hard evidence for this, just a strong hunch built on actually writing code every day, my personal sense is still that AI performs more efficiently and more accurately in R and Python than in Stata, especially once you get past “does this run” and start asking for genuinely optimal, maintainable, and reusable code. Getting a working regress command out of an AI is one thing, getting a well structured, reusable Stata do-file out of one is still a different story.

Making charts still makes me want to scream

This one is personal, but once you have learned to think in the Grammar of Graphics, layer by layer, mapping aesthetics to data, you cannot unlearn it, and Stata’s graphing syntax feels like going back in time. The twoway family of commands gets the job done, and there are some genuinely nice user written schemes floating around, but building anything beyond a standard bar or line chart usually means fighting the syntax more than the data. I do not think I will ever stop complaining about this one, sorry StataCorp.

It cannot keep up with actual big data

At some point, a dataset stops being a .dta file that fits comfortably in memory and starts being something you need distributed computing for, and Stata is just not built for that world. Try loading something like Brazil’s RAIS (Relação Anual de Informações Sociais) database directly in Stata, and you will understand quickly why that kind of data ends up hosted in something like BigQuery instead, it is simply too large, and Stata has no native answer for a Spark style distributed backend. To be fair, connecting to external databases has gotten genuinely easier in recent years, JDBC support means you can query a database directly from Stata now. But it is another example of a feature that arrived late, R and Python users have had proper ORM tooling and database connectors in place for a long time already.

So why do I still bother

Because in my corner of the professional world, rule of law data, governance indicators, development adjacent policy research, Stata is not going anywhere, and pretending otherwise does not help me collaborate with the people I actually need to collaborate with. Every time I get a dataset from a partner organization, there is a real chance it comes with a do-file attached, and being able to open that do-file and immediately understand what happened to the data is worth more than my personal software preferences.

So no, I still do not love Stata. My heart, and most of my actual coding time, is split between R and Python. But I have stopped treating fluency in Stata as some kind of professional betrayal, and started treating it the way I treat any second language, not the one I dream in, but one that lets me talk to more people, read more of their work, and occasionally understand a joke I would have otherwise missed.