Ask HN: Why Did Python Win?
I remember much of the positive sentiment around Python in the early days being less about Python and more about how powerful Perl is but Perl is Perl. Python being the nice and clean version of Perl meant it got all all the praise of Perl while enjoying the reputation of having none of the failings of Perl. In hindsight I think Python needed to stand on its own right, not just as a better Perl, but yet here we are. I think hindsight will show we should have considered the defects of Python more deeply. I know the lispers saw them but no one listens to them. Today Python is most dominant language on the planet and Perl is all but forgotten.
If you survey the language landscape now, a language can be much better than Python but never get the chance Python did just because it happened to look a bit better than Perl. Which is absurd to me.
2. Python is conceptually compact, dominated by hash tables with string keys. The initial leader in the ecosystem, Perl, is conceptually sprawling and difficult to reason about.
3. Python also took lessons from the Unix shell, a mature environment for accommodating beginners and experts.
4. Python had a formal process for integrating C modules from early on.
5. Python’s management has an elegant shearing layer structure, where ideas can diffuse in from anywhere.
6. $NEXT_GENERAL_PURPOSE_LANG (Ruby, Go) weren’t enough better to displace Python. Both were heavily influenced by Python’s syntax, but ignored the community-centric design process that had created that syntax in favor of We Know Best.
7. Speaking of open source entrepreneurialism, JavaScript has become a real rival thanks to the Web (and node), but it is handicapped by the inverse failure mode: where Go is dominated by a handful of Googlers, JavaScript was effectively unmanaged at the STDLIB level for a crucial decade, and now it can’t recover. (I’d also guess that having to write a module system that works well in the chaos that is Web clients and simultaneously the Unix world is a daunting design problem.)
8. Python got lucky that data science took off.
[1] https://ospo.gwu.edu/python-wasnt-built-day-origin-story-wor...
9. Python got lucky that its inevitable screwups (Python3) didn’t quite kill it.
10. Swift and Kotlin both define programming as serving the compiler (specifically LLVM) rather than serving the coder’s problem. (I haven’t discussed Rust so far since it isn’t attempting to compete with 98% of Python use cases, but if you squint you can see it as going one step further than Swift and Kotlin and in effect forcing the coder to be a sort of human compiler who thinks in types and memory management. This is not a criticism of Rust, BTW.)
0. And behind all of this is Moore’s Law and the demographic explosion of programmers. Python was an implicit, perhaps unconscious bet that if you served people thoughtfully, the tradeoffs with serving the needs of contemporary silicon wouldn’t matter as much.
As he described it:
"But after that first year [of college], it turned out that the real math I wasn’t particularly good at. And I think there were some great teachers at that university and some super cool topics being taught. And I couldn’t keep up. I remember something about a particular form of group theory. And I knew—and a few other students who were like, “Oh, you’ve got to go do graph theory, or group theory.” And I was like—it went way too fast. And I suddenly realized I didn’t have the skills to keep up with those topics. But in the meantime, starting almost from my first month I entered the math department, I had been learning to program because they had I think one of the first-year undergraduate courses was programming in Pascal."
Quoting from 'Oral History of Guido van Rossum', https://www.computerhistory.org/collections/catalog/10273871...
He got his degree in CS at a time when CS at the University of Amsterdam was part of the math department. He also took CS classes at Vrije Universiteit, under an arrangement where students could attend courses at either school.
He didn't study group or graph theory and was not interested in mathematics. Instead, he took computer classes:
> the programming classes I got at University of Amsterdam in the math department, were a pretty haphazard collection of topics that didn’t interest me. I mean, sometimes the topics interested me. I mean I remember one semester we were all learning ALGOL 68. And the teacher was super excited, but other times, it was like numerical programming, calculating what the error is after a certain set of matrix operations. And I was not interested in anything involving floating-point numbers, basically. But Tanenbaum, or his group [at Vrije Universiteit], taught topics like operating systems, databases, networks, and languages, I believe. Yeah, Tanenbaum himself did a class where he taught like seven non-mainstream programming languages. And that was all I just soaked that up.
The math department had to "customize" his degree "a little bit for [his] situation."
There is no indication of being a trained mathematician, neither as someone trained to do mathematical research, nor trained to apply mathematics to other problems.
I have an undergrad degree in math, having taken the course for both pure and applied tracks, and even when I was fresh out of college I wouldn't say I was trained to be a mathematician.
The slow parts of your python program can be rewritten in rust or C, your choice. So refreshing.
It didn't try to be everything (high performing, compile-time static typing) to everyone (novice, intermediate, expert, academic).
It instead made it easy to solve critical needs (e.g. highest performance hot code) by interoperating with an existing solution that did them well.
It is far and away the most common footgun novices run into when I'm answering questions about why their code doesn't work.
It was, in my experience, before Python 3 clamped down on mixed spaces on tabs; before the `SyntaxError`s got better (for example the handling of `try` without `except`); and before VSCode got so popular (such that all the novices were using who-even-knows-what random editor and you had to figure out every time how they were actually producing the indentation, whether it does/can convert tabs to spaces).
And, oddly enough, before LLMs. Not so much because they explain anything all that well, but because lazy clueless people now get correctly indented code generated in-place rather than copying and pasting from Stack Overflow and not having any clue how to make the pasted code line up properly.
But now I far more often see people who are clueless enough that they can't distinguish the REPL from a command line ("why is `pip install ...` a syntax error?"), or are struggling with whatever is the latest attempt by the Python team to make Python easier to install and manage on Windows, or who seemingly can't wrap their head around the idea that Python has to know where on disk to look for the installed libraries (or why it won't work to just put everything in the system environment). And in terms of the language itself, probably the biggest stumbling blocks are things like command-query separation ("why can't I `foo.append(bar).append(baz)`?") and just using functions properly (which typically boils down to "why doesn't `return foo` let me refer to `foo` in the calling function?", but generally stated completely differently).
1. It becomes much more difficult to tell beginners where the end of a block is, because the ending of the block isn't something you can describe verbally. You have to point to it instead.
2. Students who might be prone to using the wrong number of "}" or "end" tokens to close a block will instead un-indent the wrong number of times. It doesn't prevent the kinds of mistakes that mismatched parens tend to cause.
3. When closing a block, the thing you're trying to align a prior block with might not be on screen any longer. I don't know why, but I've seen more off-by-one spacing gaffes after the close of a nested block than I ever expected to see.
That said, I don't doubt that Python arrived at the choice of whitespace blocks empirically. However, I highly suspect that the majority of the users learning how to program in the late 80's and early 90's were familiar with monospaced text, which was ever-present in most productivity applications of the day, and thus easier for them to reason about.
And to be clear, I don't really care that much about Python's whitespace blocks. I don't like them, but I'm at the age where I feel like quibbling over minor syntax gaffes is beneath me, and Python is my top "swiss army knife" language when I need a job done quickly. My only point is that I feel like whitespace blocks are a relic of the time when they were developed, and I don't think they are as beginner friendly as advertised.
EDIT: After stepping away from the post, I realized that in my perfect world, a beginner language would look a lot more like Lua than Python. Then I remembered how popular Roblox is, and how popular Garry's Mod was before that. Given the success of those platforms, there might be something to it.
Around 2010, I was talking about this with friend about this failing of mine, and he said "you should try python, I've heard it is popular with non-math folks." So I bought a book, and as soon as I opened it, I could just read it. It took me a couple days of reading to wrap my head around object orientation, but on the functional side, I could have written fizz buzz like, maybe half an hour after opening the book.
Humans have logic pre-built into our brains, it's just that we use natural language as our syntax. Python cleverly used as much of the natural language syntax as was practicable to remove the barriers to entry for non-math majors. Whitespace is perfect example of a natural language syntax feature.
Remember that Apple SSL bug "goto fail"? That was a whitespace bug, because even if the C feature predated python, everyone's eyes had been trained to slide right off that particularly crass shortcut as python was widespread by that point.
Python executes like it reads, which seems like a positive feature to me. Makes errors like C's two-line if block impossible.
I don't know what you mean by this.
>The whitespace thing is actually one of python's major flaws. That feature attaches syntactic meaning to non-printing characters. From a human standpoint, there're many examples of silence having some kind of meaning. From an engineering standpoint, that entire methodology is insane.
It's not non-printed characters, it's alignment. The period is a parallel for the semicolon in programming, to signal the end of a unit, but the whitespace in python is a parallel to the bullet point, or poetic stanza. Those both parallel to python in the form of atomic statements.
Most people's concern is the hanging indentation. Here, I would argue that we can effectively prove that hanging indentation is vastly more parallel to natural language than braces. Simply search for "handwritten recipes" and you will see that in a natural language assembly exercises -- effectively a real world parallel to programming -- human beings naturally default to hanging indentation when grouping sub-categories of items together.
https://duckduckgo.com/?q=handwritten+recipes&iar=images
Does this parallel to the jargony math you'll find in math books? No. But it trivially flows from human beings in the real world, and there is nothing formally incorrect in the syntax. Thus, we would likely find that layperson would intuitively understand the hanging indentation, where as braces as syntax is jargony, and must be learned.
I see where you're coming from. However, I would counter that in the use cases you've shown, as well as all of the use cases I've seen in the real world, there are important differences between them and Python.
1. Hanging indentation is most often used in things that are small in scope, where you can easily see both the start and the end of the list. Python blocks can grow without bound.
2. Hanging indentation in real life doesn't require perfect alignment. Python does.
Spaces vs tabs, sure, that's an argument.
But it doesn't seem reasonable to argue that {something that is visible in a text editor} is different than any other kind of character.
It's not like Python was using the bell ASCII or somesuch.
Ruby’s syntax is pretty accessible and powerful and Matz was explicit about having developer happiness as a design goal.
Theres a lot of network effects as well. The more people were using it, the more people will use it.
If there is really a killer argument for Perl over Python that was overlooked in all those years, why don't you say that argument, or even better, write a blog post explaining why Perl is better than Python? Then we could discuss that instead of nebulous "different ways"/
Isn't that the crux of the issue? Perl was great if you're a hacker who 'got' it. For the remaining 95% of the population, Python worked.
Lisp/Scheme are also beautiful to those who 'get' it.
> I still don't understand how it won, stealing the halo of a language while having nothing of the sort.
Plenty of people have already told you. 95% of programmers do programming to get the job done. The linguistics grad student I knew 20 years ago did his work in Python because it was easy (he had no programming background). He would have simply changed his thesis topic if Python didn't exist. He would not have learned Perl.
Perl was for hackers. Python was for everyone.
It’s really not the crux of the issue though. “Better than Perl for normal developers” is not a high bar. Most languages clear that bar whether they are successful or not. This is certainly not the only reason that Python became so successful.
Tangentially, in my experience Perl was great for one liners and small glue projects. I never saw significant, valuable works of code built in Perl even when I worked at a company (Yahoo) that widely used Perl. I am convinced that much of Perl’s beauty is in its cleverness and’s not in its utility for large projects.
Dial the clock back to 2002, and this statement is not true. Perl became popular not because of its beauty, but because of it being extremely effective glue. It was a language to get stuff done while writing little code.
The only mainstream alternative was Python.
1. Why did Python replace Perl?
2. Why did Python become so extremely popular?
The answer to the first is because it’s better than Perl for so many engineers in so many cases. The answer to the second is much broader.
In that case, yes. Perl is beautiful. Python sucks and only succeeded because idiot developers couldn’t see the beauty of Perl. Python is poorly suited at every job except stealing potential Perl devs.
Feel better?
Readability, explicitness, one way to do things are examples of great design taste. Perl was the opposite of all that.
Of _course_ boring is better. How could it not be? If you are trying to solve a problem, the last thing you want to be thinking about is the language itself.
The language you adopt to code up a solution should force you to think clearly, but no more than that. Executable pseudocode is as close to an ideal state as you can get for a high-level language.
Perl, meanwhile, was filled with multiple ways to do things -- famously and absurdly thought of as a virtue -- reveled in side effects, and did so much implicit work with variables and flow that perl was often unreadable by anybody else, including the you of three months from now.
"Python did everything other scripting languages did, but in a cleaner and more comprehensible way" tells you most of what you need to know about Python's victory, but the death blow was delivered by the perl community's love of complexity, which led to the disaster that was Raku.
By the turn of the century, it was clear that python 3 was a better plan for the future than perl 6.
> By the turn of the century, it was clear that python 3 was a better plan for the future than perl 6.
Work on Python 3 wasn't even announced until 2006, and Perl 6 in 2000.
I believe more in the ecosystem, specifically how the computer vision and machine learning movements have adopted python extensively as frontend language (the heavy weightlifting is still doing in C++). The exploit of numpy has brought many many use cases into the language as well.
So why not make it have syntactical meaning since it’s already there in 99% of cases?
It does feel weird at first but honestly it’s not something you’ll think about much after a while.
The fact that YAML also won in its configuration file niche doesn't give you pause?
That's like, your opinion. Python was explicitly designed being easy to learn, borrowing heavily from ABC, which actually experimented with different syntaxes to see what works and what doesn't. The indentations apparently helps a lot with this, along with ':' before the introduction of indented blocks.
Python is simple to read / write and easier to reason about, especially for people that need a programming language to solve a problem but are not software engineers.
The reason it won, especially in data analysis, is because most data analyst are/were not software engineer and Python feels more natural to people.
The indentation is not a big problem when a decent text editor is used
As opposed to the not required indentation that literally everyone who writes code ever does anyways?
> believe more in the ecosystem, specifically how the computer vision and machine learning movements have adopted python extensively
What came first, the chicken or the egg?
There was no easy for people who wanted to get something done in a simple interface.
Now there's tons of stuff they're deathly afraid of removing, that they would never remotely consider adding if it weren't already there. (If you don't believe me, have a flip through proposals on discuss.python.org for new additions. People think of Python as a language that's constantly adding and changing stuff and inadvertently causing breakage as a result, but it's actually very conservative relative to the volume of proposals.)
This is also a big reason why AI assisted programming will wholesale replace Python programmers.
If your are optimising for people who wish to remain at beginner levels all life, and that replaced people using power tools to solve harder and bigger problems. It shouldn't be surprising that now some automation will replace you.
* Python has clean and readable syntax that a complete beginner can understand -- it's really close to the pseudocode you might use for teaching.
* Python has a good standard library, so you can do a lot before you need to work out how to install more (and, reproducibility concerns aside, `pip install` is really simple once you get there)
* Because it was easy to pick up and easy to use for teaching, it took over some niches like stats in academia / data-analysis, where the people doing the work aren't professional programmers but just need something they can hack together. Once NumPy existed, people had minimal incentive to move away.
(Insert Marge Simpson "I just think it's neat" gif here.)
That's putting it lightly. Many jokes were made at Perl's expense on that topic, but
is a valid Perl program to grep for lines that are the file's name. One of the jokes was that it was a write only language and it was only half way a joke. Coming back to a pile of magic variables months later with no comments, omfg. Meanwhile, Python sometimes scarcely even needs commenting if it's a short script if the writer uses descriptive function and variable names.Perl's downfall, was that coming back to a ball of Perl mud after say 3 years and have to fix a bug, due to lack of classes and Perl 6 being delayed forever, you were in for not lot of fun. Python isn't perfect and that's why it's grown types, but Perl was seriously write only at times.
Nobody should be spending a day writing Python to do work that can be done using a vim macro in like 5 mins. Or spend a year doing in Python what can be done in a week in Perl.
>> $\=$/;for(@ARGV){open F,$_;while(<F>){print if/$_/}}
There are lots Perl one-liner patterns, once you learn to write them. You are basically saving yourself writing many dozen man-hours of Python/Java coding work.
I remember telling my manager during the Perl days. A 10 year Java experience guy looks great, but thats basically a junior Perl dev with 6 months experience.
There is nothing to feel great about wasting effort and more importantly time.
Not sure your time-saving thing really works, especially if 99% of problems you have are not solved by a perl oneliner.
That's because if you don't have a paradigm of thought, you are not likely to reach for a tool that works there.
Most of the times, I have seen Java programmers watch in total awe that their pet weekly project was basically a vim macro that they could have done in like 3 - 5 mins.
I'm guessing most Python/Java programmers would find it impossible to work in project which doesn't involve a database, XML, or json. Those languages are not designed to work with a data or a compute paradigm outside of these formats.
You use a real language for these projects because it allows someone besides yourself to collaborate and maintain the project
The pet project you write to replace that Perl one liner is also write only once project. The only difference is you waste years of your life doing what we do in minutes.
There is nothing to boast about wasting your life doing things that don't even have to be done.
Which is why the tasks you're talking about are being delegated to LLMs that don't GAF what the target language is.
You’re struggling to understand Python’s success because in your head the primary reason Python succeeded was because it happened to be prettier than Perl, and you can’t wrap your head around why that’s enough. But it’s not enough. Python succeeded for many reasons.
Regardless, you’re regurgitating exactly what I said. Your gut is that Python was just a slightly better replacement for Perl. This is at best one dimension. If you can’t broaden your perspective, then this thread full of examples and arguments for why Python became popular will be lost on you.
If you’re so confident in your assessment, why did you bother to ask?
You keep saying it, but from 2000-2010, what scrutiny did it escape, exactly?
Are you saying when universities dropped Java/C++ for the introductory course and replaced it with Python, they simply threw dice to pick the language?
Are you saying all the Perl programmers who kept saying "Python will never have the power of CPAN" didn't exist?
Are you saying Eric Raymond never wrote an essay on the virtues of Python?
What more scrutiny can a language get than people writing large projects in it over time?
Basically every languages mostly escapes scrutiny except from very niche corners (usually people deeply committed to other languages that aren't actually considering alternatives, but criticizing everything that isn't their preferred language for not being their preferred language) until it succeeds, because there are enough of them that basically no one cares to put the time into scrutinizing them until they achieve a critical mass.
That's not why Python succeeded against other languages.
- Perl's decline was cultural - https://news.ycombinator.com/item?id=46175112 - Dec 2025 (460 comments)
- (!) Ask HN: Why did Python win? - https://news.ycombinator.com/item?id=37308747 - Aug 2023 (839 comments)
- Ask HN: Why is Python so popular for ML/DS? - https://news.ycombinator.com/item?id=16207834 - Jan 2018 (19 comments)
- Ask HN: Is Python dying? - https://news.ycombinator.com/item?id=11100251 - Feb 2016 (352 comments)
- Python is now the most popular introductory language at top U.S. universities - https://news.ycombinator.com/item?id=8001337 - July 2014 (362 comments)
- Ask HN: Why Python over Ruby? - https://news.ycombinator.com/item?id=682101 - July 2009 (196 comments)
- Ask HN: What does Ruby have that Python doesn't? - https://news.ycombinator.com/item?id=283639 - Aug 22, 2008 (223 comments)
Even if they ask about the syntax design people just dismiss their question with saying "syntax is not important". Python did the opposite, it focused on syntax over everything else. That caught on with beginners and now here we are.
Of course with AI Python got even more popular, but even before ChatGPT was released it was already dominant.
Python has issues, but those issues don't matter equally to everyone and every use case. Low barrier to entry, coupled with Metcalfe's law, explains a lot IMO.
I love Scheme, but not everybody does, and I can see why.
This is absolutely true.
OTOH, the "No true Scotsman" attitude that some display, that no real programmer would deliberately use Python, always says a lot about the one displaying the attitude.
The Perl 6 redesign was announced in 2000 and it has been going on for 2 decades? Python is clearly a good programming language but the Perl 6 redesign took so long that many people gave up. Then it was renamed Raku in 2019 I think.
If you were czar of the universe and could start from scratch, could a better scripting language be created? Sure. But that’s not the fact pattern, and Python isn’t bad enough at what it does to warrant starting over.
In short (all below is my opinion): it was popular in academia and got some corporate adoption, so when ML exploded in popularity it was a natural choice as the scripting language for ML tooling. On top of that it’s easy to pick up as a language, and it’s a general purpose language - there are lots of scientific tools like pandas written in it, there are web frameworks, etc.
Perl was too quirky for wide adoption and it stopped developing (Raku/Perl 6 took to long to develop), PHP was focused purely on the web, similarly JS. Ruby could have won, I like it more than Python, but outside of Japan it’s also mostly been associated with web development (because of Rails), it also lacked libraries that Python already had.
Seems unlikely. Its got its own fair share of Perl-inspired quirks.
Python is easy to learn and has an extensive library catalog. It also has massive support available online. That's why I have chosen it in the past when I needed to write basic programs for work.
With the rise of LLMs, python is now even more attractive as LLMs really excel at writing it.
Larry Wall, creator of Perl, coined the phrase, "make the easy things easy, and the hard things possible". But the things perl made easy were not always things that the market needed. Perl was very distrustful of enterprise disciplines and the perl culture "let a thousand flowers bloom" mentality (which they/we called "There's more than one way to do it"/(TMTOWTDI)) was not actually useful for organizations maintaining larger code bases/systems with large groups of mixed skill level people.
Python threaded that needle of centralizing a right way to do things (not just whitespaces) more effectively.
I also observed Scala suffering from similarly disfunctional "TMTOWTDI" dynamic in organizations I belonged to; different people had wildly different styles of solving even basic problems and it really made code hard to maintain even in smaller organizations where people came and went and new people were onboarded frequently.
Plus data science use cases saved Python's web/scripting lifespan in a way slightly analogous to AI/CUDA extending NVidia's 3D graphics-centric roots. (Although the python data science ecosystem nowdays does have some TMTOWTDI weaknesses that remind me of perl/cpan's choices of web development frameworks of the mid-2000s!)
Against Perl? Over a decade ago. 10 years ago, the only places that required Perl were either hard engineering (i.e. non-programmer EEs) or those with legacy code bases.
Over everything else? Of course not. You don't do systems level work in Python.
The problems with Python are minor (other than packaging), and not a big enough pain to adopt another language. If you really could benefit from static typing, there are already existing languages that do the job well (C++, Rust, etc).
For the majority (including even some Perl fans), switching to Python was a significantly better experience. If you now show me a language better than Python, it's really only an incremental benefit. Sure, I prefer ML languages like F#, but the vast majority don't.
It felt pretty easy to read and write, had minimal surprises, and it made writing simple programs easy. The batteries-includedness was great.
It felt like it was designed by a smart guy for practical programming, rather than by a brilliant academic who was wed to purity for maximum elegance. It accepted some warts, but them in mostly ergonomic places.
It was dictated by people who could relegate map, filter, and reduce from builtins to the library. As much as I personally even liked map in particular (I am not super anti functional programming), it's nice to realize the designer had the taste to prefer longer but more explicit programs.
As much as I disliked that particular decision, there is no doubt to me that it is just designed for lower cognitive burden when doing simple/common things.If you show both of those lines of code to a person in cs101 who has studied Java for a couple months but hasn't seen Python, I am pretty sure they are gonna understand the first line way quicker. Mostly consistent decision making like that leads to ergonomic, practical languages. And they win.
It fits in people's brains better. See also, pytorch vs tensorflow.
The main reason is to avoid npm, but also, I wanted something with more built-in defaults (my web apps have simple needs). It has nothing to do with the language -- it's more the ecosystem for me.
I considered Ruby/Rails, but it didn't seem enough better than Python and can't replace the Pandas work I need to do.
Perl has so many ways to write the same code, no two codebases are the same - it's practically different languages. Back when I was programming Perl, I remember reading my own Perl scripts I wrote few years ago, and being annoyed with how they were doing everything all wrong... because in those few years, my Perl style has changed significantly. And others' scripts were even worse!
Plus, python had all those neat quality-of-life things useful for day-to-day scripting. For example actual function parameters, exceptions (no more "or die" after each open), pretty big stdlib (I _don't_ miss having to configure "cpan" on each new machine), repr() in language core, etc..
And yes, Python got lucky somewhat - there was a need for "Perl but easier to read and friendlier to new users", and Python has filled that need. And now that need is no longer open, so it's harder for newcomers to fill that niche. But that's life in general - Rust filled the niche of "No overheads like C++ but memory safe", Go has filled the niche of "Compiled systems language with GC" etc... And once a language gets popular, network effects kick in.
Perl’s alien syntax and how there were multiple competing “best practices” put off newcomers and made it difficult to code review.
Perl also stagnated for quite some time due to the efforts to move to Perl 6, though python likewise stalled later it already had better traction at that point.
However I’d argue that Perl lost to PHP at least as much as it lost to python. PHP was revolutionary at the time for how easy and straightforward it was to do simple web programming which was one of the big use cases for Perl.
By the early 2010s there wasn't much of any use case that made sense to choose Perl. Sysadmin scripting was clearer to review and maintain in python and golang, web applications moved to php and frameworks written in languages that didn’t have the downsides of Perl.
I think there's a few key features for python that have definitely been a big help for it:
It's highly dynamic meaning you can get running with it before understanding every detail (no compile step, no static typing etc).
It may not be the best at everything, but is a decent choice for most things, making a good generic intro language for programming.
It has good interop with low level languages - this is a big deal for data science where a less technical (from a CS perspective) user still needs the performance of a language like C/Fortran/Rust/etc. Python's pattern of "use python as a high level api for libraries in those other languages" (as in numpy, pandas, polars, pytorch etc).
That last one has been a big deal recently, python has become the de-facto language for data science as a result of this.
After all these years, I assume it must measure in the tens to hundreds of thousands?
It’s in those moments of consideration that I understand humanity hasn’t done a very good job grappling with its frailty and mortality. If we had, then we’d have a crowned a winner that didn’t subjugate us endlessly to the most vapid and Sisyphean aspects of programming. Python is a lesson in managing existential angst, which I now assume was the point of it from the very beginning.
It's not absurd, it's a debatable point. I think being easy to read is definitely a desirable quality for any language, especially for adoption. Some are better than others in this field.
JavaScript would like a word!
It's reasonable to disagree, but let's not pretend that some alternative is the obvious choice.
The laws of physics as a program and math as its language is just as good as any other framing. And its a short logical hop to expect that more than one civilization would discover that language.
I'd like for Julia to fill its niche myself.
(It’s not so pretty these days though with all these type hints and other cruft that’s been added in the last ten years.)
And to be honest when you start using it, even just for simple things such as function signature, with the proper IDE it helps you catch mistakes.
But really it’s because Google, Dropbox, etc made it so. Same reason Java got popular. It’s hard to beat first class corpo support even if the actual language isn’t that great.
The Python leadership group is friendly towards beginners and people with non-traditional backgrounds, and they actively reach out and recruit those folks to participate. It's also one of the least toxic developer communities I know of.
That matters a lot in a field like data science or cybersecurity, which has a lot of people who don't have traditional SWE backgrounds.
The language is pleasant and readable to use and has a lot of features built in, which Perl did not, but I think that's much less critical than the network effect of being a (1) welcoming and pleasant community who (2) actively recruits new fields of people.
Python is a nice language, but so are others. I know of three main libraries -- three main "I can get stuff done" -- eras with Python, and I think these drove Python.
1. Beautiful Soup. Early/mid 2000s, web scraping and website / XML / HTML data manipulation were a thing; this library came along and made it easy. I'd heard of Python before on places like Slashdot; it was cool but Perl was more spoken of. Then, in my anecdotal experience, what I suddenly read about was not Perl or Python, but Beautiful Soup.
2. NumPy / SciPy. Python was apparently written with numerical computing in mind, and NumPy in its current form arrived a bit after BS. Early 2000s: stats and data vis folk were using R. By the 2010s, I was hearing about all these people that were not using R, but were using NumPy and SciPy.
3. AI. Until a few years ago, it was all SciPy, then with the current era, everyone is using Python -- for AI.
None of this is the language, per se. People were not 'using Python'; they were (say) using SciPy.
I think Python benefited hugely from having not a single "I can achieve stuff" value proposition, like VB did; it had three consecutively in a row.
These all had roots well before they became well-known. Enthusiasts, initial design, years of work and usage, and 'suddenly' out of nowhere everyone is using it. The common factor there is likely Python's design and community; there would be lower level reasons for Python's success than the things it let users achieve, and those would be, what incentivised or led to Python being used for those libraries (value enablers) in the first place. I can't speak to that; I wasn't there in the Python community in the 90s or 2000s.
[*] Not always: Rust's value is in its memory system and safety. That is not a library but inbuilt, yet that still is something you can do, a goal, value, something you achieve using the language and thus you turn to the language in order to achieve. Rust minus that would need some other reason to be used.
Sure, but the language itself has a lot to do with why library writers choose to target that language.
Multiple levels!
By GitHub contributor counts, August 2025 marks the first time TypeScript emerged as the most used language on GitHub, surpassing Python by ~42k contributors
https://github.blog/news-insights/octoverse/octoverse-a-new-...
There are many clear reasons imo.
The excessive mentions of Perl are weird — it, along with PHP are prime examples of awful taste. Those are the languages that only gained any traction because they happened to be available at the time, not because they were any good.
Now it _may_ be that the erroneously named "serverless" architectures that are the soup du jour will make this less true, but I don't have enough insight on web stuff to know how that's proceeding.
Perl6 was a much greater mess than Python3.
I'm more surprised that Ruby didn't do better.
As you say,
> Network effects did the rest.
In an alternate set of universes, Ruby has Python's current position, and you are wondering why Python didn't take off. (But I suspect Ruby evolved fairly differently in those cases.) The universes where both are popular are much rarer.
It has. That just wasn't where the foothold was. Python has had several moments propelling it to its current position. "The early days" absolutely did not set an inexorable machine in motion. It took further boosts from fields like data science, machine learning etc. that would likely never have touched Perl even if the Perl 6 story had turned out much better.
> I think hindsight will show we should have considered the defects of Python more deeply.
There are many. I personally find that many of the commonly proposed ones are not that important, while everyone else is ignoring much more serious things. But so it goes. You can say these sorts of things about all the popular languages. "Although practicality beats purity."
> I know the lispers saw them but no one listens to them.
Lisp has had enormous hidden influence on how people write code in other languages, honestly. SICP is a revolutionary work. It just turns out that homoiconicity is not hugely useful the large percentage of the time that you don't need metaprogramming, and that the structure of the code is harder for humans to grok when it isn't explicitly marked with a variety of punctuation (rather than just parentheses).
> If you survey the language landscape now, a language can be much better than Python but never get the chance Python did just because it happened to look a bit better than Perl. Which is absurd to me.
This falls in the category of life not being fair. If you have your own ideas about how to make a Python-killer, I'd encourage you to pursue them anyway.
But also:
> It just turns out that homoiconicity is not hugely useful the large percentage of the time that you don't need metaprogramming,
It turns out that metaprogramming, like anything else, has many possible levels, and that for the shallower levels, Python's reflection, magic methods, and metaclasses suffice without too much heartburn.
- Face it, decorator syntax is kinda ugly
- History. Decorator syntax is new
- For things which will be repeatedly subclassed, the metaclass automagically tags along
But it's almost certainly easier for a maintainer to look at a decorated class and figure out what's going on.
Python gets a lot of grief from the perspective of people who are frustrated because they didn't start off using virtual environments and now their global python package namespace is a nightmare. Legit criticisms, but for many non-developer python users those problems are somebody else's problems. Given the readership on this site... they're most likely our problems, but we aren't the users that python is made for. We're support for those users.
It's winning because its audience is not code specialists, but other kinds of specialists which sometimes need to use code. Their work often has a sort of immediate importance that ours often doesn't. It's not evaluated based on whether the techies like it, it's evaluated based on whether the scientists, the analysist, the students, and the {non-computery-engineering} Engineers like it.
Maybe? I mean, if people aren't noticing these issues and you are, how are they relying on your support?
> It's winning because its audience is not code specialists, but other kinds of specialists which sometimes need to use code. Their work often has a sort of immediate importance that ours often doesn't. It's not evaluated based on whether the techies like it, it's evaluated based on whether the scientists, the analysist, the students, and the {non-computery-engineering} Engineers like it.
There is no bright line. I'm a code specialist. I use Python as a tool to help build other code. I don't have any venv problems because my git repo has everything I need in it.
Also, in a previous job, I was responding to tickets of that kind (e.g. "why does installing this version of foo prevent the bar from running at a all?").
Others provide support in other ways. The guy racking and stacking GPUs at a data center somewhere is doing so, at least partially, in support of some specialist wielding python to move data around.
Sure plenty of specialists do their own stunts, but plenty others do not and instead have support, institutional or otherwise, for that kind of thing.
I think we agree these are not typical end users.
> Others provide support in other ways. The guy racking and stacking GPUs at a data center somewhere is doing so, at least partially, in support of some specialist wielding python to move data around.
I mean, the farmers help to feed me, too. Where do you draw the line?
We don't notice them because they're not participating in conversations about which programming language might be suitable. Instead they're having conversations about whether Python is necessary or whether they can get away with a spreadsheet.
I never got to the "nightmare" stage before learning about venvs.
But it's still nice sometimes to have an environment ready to go full of popular, non-conflicting things to play around with a REPL in.
subshells would let you nest venvs so you could have a "sane defaults" venv, and then you could descent into madness with another "wacky experiment" venv, and to return to sanity you'd just exit the subshell. As it is, deactivating takes you all the way out to the system package namespace (or maybe you can nest them, not sure, but it's up to the venv implementation and not your OS to restore the intermediate env).
The venv is just the folders and Python stubs.
The activation script concept is probably just what happened to occur to Ian Bicking first. But also maybe the subshell UX isn't so pleasant on Windows?
Certainly others have implemented subshell-based venv management.
> As it is, deactivating takes you all the way out to the system package namespace (or maybe you can nest them, not sure, but it's up to the venv implementation and not your OS to restore the intermediate env).
The effects do not nest, at least not with the *sh activate script. You'd need to implement a stack of old environment variable settings.
But I think the use case you describe just doesn't resonate with a lot of people.
Yeah I suppose "flat is better than nested" is right there in the zen.
I guess I'm just an oddball. The idea of exiting all the way up to the root and finding nothing installed there except for the ability to descend into one or more specialized transient environments feels so... clean to me.
It’s why Windows beat DOS ( and NT beat Warp ) and why Apple then beat Microsoft.
Easy always wins.
One of us started playing with Perl. He ended up dropping out and going to work as a SysAdmin.
One of us started playing with Tcl/Tk. He ended up changing majors and going into UI/UX testing.
I started playing with Python, which at that point was, I think, at 0.9.2 or something. Eventually, after some twists and turns, I went on to work on ML stuff.
Is there a lesson in that? Probably not, but somehow I find it amusing all the same.
1. The Rise: 2005 - 2010 Google hired Guido van Rossum in 2005 (stayed on for seven years) and gave corporate blessing that made everyone comfortable with moving from Perl to Python. It was seen as the language of scientists and smart people so a lot of people working in misc. languages like Fortran, MATLAB, Perl moved here. To remove the speed issue the official Google mantra was "Python where we can, C++ where we must".
2. Near Death: 2010-2015 Python almost died due to self inflicted wound from the 2 -> 3 transition and there was a good chance it would have gone nowhere like many languages before. Guido also moved away from Google and Google seemed to have shifted it's attention to Golang (apart from the standard C++ and Java)
3. Resurrection: 2015-Now Data science and ML took off and Python was right there thanks to the initial sponsorship from Google and ecosystem of scientists and engineers who were familiar (including working in the two-language mode). There was no language that could rival at this point.
Most of the syntax, power considerations etc.. are side shows as most scripting languages just tap into very powerful libraries written in c/c++/fortran or wrappers around shell. Doubt that distinguishes Python to the point where it has become so dominant.
Python is C/C++ but without syntax decorations and pointer problems and who cares about speed when CPU cycle is so cheap.
Python is shell but you can build large projects with a shebang change
Python is Java but with less verbosity and no company behind
If one only affords to learn/master a single language (which holds for the majority), this should be Python.
The only drawback, there is no Python interpreter in browsers (like JS and PHP). But then Python might have faced anticompetitive measures :-)
It is trivially learnable, absurdly flexible, and unmatched in ecosystem leverage. No simpler language delivers comparable reach.
Python may not be so suitable for systems, real-time, or performance-critical work—that’s Rust, C, and C++.
Nevertheless, every serious engineer must know Python, just as they must know shell/bash scripting. Non-negotiable.
- the first and MAIN reason is excellent windows support. Nobody wants to say this, but it was the first unix friendly community for a good scriting language to not shit on windows users.
- batteries included is frawn uppon today, but it was a BIG deal back then
- python had the best c integration system after lua and got the Numric lib because if that. It became numpy.
- it was dynamically typed, but strongly typed. No ===.
- optional parenthesis for ruby and symbols from perls were a repellant to many C and java users.
- the error messages were better than the competition.
- lisp shell without lisp
- docstrings and help()
- the packaging ecosystem that everybody craps on today was actually the best at the time. Ruby's was AWFUL at the time.
- one of the first scripting language with good namespace. Ruby could have been that but killef it with monkey patching for years.
- python found ground outside of the web unlike php, js and ruby very early
- python devs were willing to work with os devs to improve integration, and so linux and mac got system tools written in python
- django and twisted were amazing at the time. The dev server without apache was a killer feature
- google advertised they used python for the search engine and youtube. Then HN successes like reddit znd dropbox. It became so famous.
It was not inevitable at all. Just a collection of random stuff.