Ask HN: Why did Python win?
My impression is that in the ‘00s, Python and Ruby were both relatively new, dynamically typed, “English-like” languages. And for a while these languages had similar popularity.
Now Ruby is still very much alive; there are plenty of Rails jobs available and exciting things happening with Ruby itself. But Python has become a titan in the last ten years. It has continued to grow exponentially and Ruby has not.
I can guess as to why (Python’s math libraries, numpy and pandas make it appealing to academics; Python is simpler and possibly easier to learn; Rails was so popular that it was synonymous with Ruby) but I wasn’t paying attention at that time. So I’m interested in hearing from some of the older programmers about why Ruby has stalled out and Python has become possibly the most popular programming language (when, in my opinion, Ruby is the better language).
855 comments
[ 2.9 ms ] story [ 392 ms ] threadThat said, Python was always more popular than Ruby to begin with (more jobs, more programmers, more college CS classes, more books), even in 2000-2010. Ruby was liked, but was only hot because of the Rails connection.
Python is very simple making it easy to learn. Thus, it became more and more popular for fields where programming is not the main task, like science. It is also very easy to extend with C. So, these fields could bolt on time-tested scientific code into their Python scripts.
Ruby seemed to be entirely tied to Rails.
When the 00s and 2010s came with needs for web development and scientific computing for big applications (e.g. ads on social media), there were multiple language options for web development but really only one that made it easy to onboard academics into the task of building software systems.
From there, it was just a feedback loop, and when deep learning became a major field, the ML community was already knees deep in Python, so it was hard to justify making tools elsewhere.
Meanwhile, it seems to me, that Rail's appeal (and with it, Ruby) was taken by Node's promise of using the same language on both server and client, and more generally diluted by the fashion waves of web dev.
If you want to swap Python for another language in scientific computing, you will soon find annoyances that certain packages are missing, or don't talk to each other well, or aren't optimized. If you want to swap Ruby for another language, you just use the other language web dev library and that's it.
As an aside, Julia has been the promised replacement for Python for over a decade. It tries and does replicate the package ecosystem, the ease of use, extendibility, etc. It also goes out of its way to be able to use Python packages out of the box. But it just seems to be very hard to convince practitioners to go to Julia for just some small performance changes.
The build infrastructure for ATLAS used the CMT tooling, written in Python.
The Summer School of Computing 2004 had several sessions related to Python in the context of grid computing.
I’d be interested in going one step further and asking why that was. Rails is great, but so is Ruby, but normally a great library like Rails helps attract developers to the language. Rails is the only example I can think of where a widely popular library (ostensibly) leads to fewer users of the language for other purposes.
Ruby's monkey patching convention might make this worse.
It was a fullstack position with some Ruby scripts here and there mostly centered around scheduling. Had a leetcode style takehome that requested I build out a pretty simple reservation system with time off and quarter hours and stuff like that.
I boot up into the leetcode environment and was surprised at just how many things were Rails-specific, rather than being in the ruby STD lib. Completely threw me off since I suddenly had to figure out how to wrestle the Date STD lib to work for me, and anything date/time related is my personal hell :)
Chef, Puppet, Vagrant, Logstash, etc are not web development.
Ruby dominated (dominates?) DevOps tooling.
I think also that dominance has mostly faded. When I think of languages that dominate devops now, I think of Go, and I say that as someone that dislikes Go.
Ruby isn't the go-to language there anymore... probably because GoLang compiles statically.
I would argue that there's little difference between them in ease of learning. I personally found Ruby easier because everything being an object with methods and no free floating functions felt more natural and easier to look up. i.e.
string.length
over Python
len(string)
To me in general Ruby is the nicer feeling of the two, just generally more "friendly" and "human". Whether those are desirable traits of a language is up for debate but I think there could stand to be more language with such a flavor.
Python's challenges are superficial syntax; the semantics are extremely uniform everywhere and don't suffer from special cases galore.
So, if you copy that code snippet and run it as an independent script, it would just not work because it was a RoR monkey patch method.
Worse, the implicit imports mean that unless you have a global view of which files and gems are require-d, you don't know what your code is actually going to do.
That, and coworkers suddenly feeling at liberty to override `method_missing`, abusing `bindings`, and all that stuff, makes it really hard to like the language if only for its tendency to bring out the worst in people.
I don't know the current state of the RoR ecosystem but back then when both languages were competing for similar mindshare this was a massive turnoff.
Then it just snowballed since that time.
https://madnight.github.io/githut/#/pull_requests/2023/2
https://insights.stackoverflow.com/trends?tags=python%2Cjava
Maybe it is because we consider Typescript to be a different language? The rise of Typescript has eroded into the use of Javascript proper quite a bit. Standing alone, I could see them being losers to Python overall. But at the same time Python 2 and Python 3 are different languages, yet seemed to be grouped together, so is there justification for Javascript and Typescript to be divided?
And now the era of Textual (https://textual.textualize.io/) is here, python may get the spotlight even more.
They were, but Python is close to 5 years older than Ruby (February 1991 vs December 1995), so in the ‘00s, Python was significantly older than Ruby.
Ruby also was more or less a Japanese-only thing until around 2000. https://en.wikipedia.org/wiki/Ruby_(programming_language)#Ea...:
“In 1999, the first English language mailing list ruby-talk began”
“In September 2000, the first English language book Programming Ruby was printed, which was later freely released to the public“
In contrast, Python was posted on alt.sources from the get-go (https://en.wikipedia.org/wiki/History_of_Python#Early_histor...).
So, effectively, Python had about 9 years head start on Ruby in the English speaking world.
> when, in my opinion, Ruby is the better language
IMO, its flexibility makes it deceptively simple. Certainly, early users used its flexibility a bit too much to implement useful functionality that felt like spooky actions at a distance for newcomers.
And after that it still took quite a few years until "English support" really became first-class and comparable to Python. I looked at Ruby around 2002-2003 or so (I was looking at many different languages back then, pretty much anything I could get my hands on), and lots of Ruby stuff was in Japanese or poor English.
That's all fine, but I specifically remember that was the major reason I ended up not using Ruby at the time.
(I did end up programming a lot of Ruby many years later, and for what it's worth I do prefer Ruby for most things now)
If the documentation is bad you can read the source, but if you need to grok 3 layers of metaprogramming living in unpredictable locations before you can do that there’s no way to advance (practically).
Understanding that Python was established years before Ruby was being discussed answers the question of why Python is preferred for many use cases.
Yeah, that’s basically why.
Back in its heyday, Ruby had two basic niches. The bigger one was Rails. Rails is still alive today, but after the move towards richer frontends a lot of the hype, and consequently the developers, followed that trend into the JS world. It’s obviously possible to have rich React frontends and Rails backends if you want to, but that isn’t quite what you got with “omakase” Rails.
The other niche was in devops tooling, e.g. Chef and Puppet. But that space moved towards containerization and all of that tooling, more or less, got written in Go.
Python has honestly had some opportunities to die out (2->3 transition, type hinting missteps, incredibly slow, etc.) but survived because writing extensions was always easy and it was taught a lot in universities.
The future of programming is describing the majority of programs in something thats even closer to English, and then fine tuning it with something like python, all of which will result in natively compiled optimal binary.
C++ got popular because it managed data structures under the hood automatically. I.e, you didn't have to keep track of memory offsets or function pointers.
Java got popular because it did that and also managed memory allocation under the hood automatically.
Python (and Javascript) got popular because it did all of that and also managed types under the hood automatically.
The future is exactly this. Some language (or Python 5 or 6) is going to do all that except manage common processing algorithms for you automatically. For example, you will not need to import a library to convert xml to json, the .toJson call will be put through an AI inference algorithm that will essentially generate the required code for you on the fly, and more then that, it will do it in a much optimal way because it will recognize that the xml data follows a particular structure so it can optimize the search of the tags rather than doing a generic approach.
The overwhelming advantage in ecosystem breadth and depth it had for this reason was insurmountable, even once Rails drew more attention to Ruby. There’s a whole bunch of technical advantages and disadvantages of each when you look at the language and core implementations, but I don’t think they were really the factors that led to the different relative popularity of the two.
Python and other dynamic languages don't "automatically manage types", they just let you not write the types down in the code. The types still exist and need to be managed by the programmer. There's zero cognitive load improvement there.
As for the AI stuff, lol. I see no point discussing concepts so far out of reach they're in the realm of sci-fi. What you're describing is just magic compared to what we can do in 2023.
We already have languages that automatically pick the best algorithms by the way, in the form of declarative languages like SQL. They don't seem to work very well outside of the realm of fetching data from databases.
If it wasn't as flexible as it was, another language would have taken it over.
>Python and other dynamic languages don't "automatically manage types", they just let you not write the types down in the code.
They do. They carry dynamic type information during runtime, and can be modified during runtime.
>What you're describing is just magic compared to what we can do in 2023.
Then you must think that stuff like branch prediction, and compiler optimizations are magic as well.
Ruby's popularity for what it was, was heavily tied to Rails. As that space progressed, a lot of people came to dislike it as much as anything, and maybe more. There are a lot of ways it didn't work so great and those warts made more and more avoid it in future projects.
That's my $.02. I started with JS as well, but in '96 and through classic ASP (JScript and VBScript) through VB6, .Net (and C#) then into/through Node.js etc. I also dabbled in PHP, Ruby and a handful of other tech along the way. Python feels like a massive gap in my knowledge base at times, I have a few books to read, but not much in terms of opportunity/need. And the time I've spent on Python, I feel like I'd rather spend that time leveling up in Rust.
- The documentation in the Python ecosystem is generally better.
- There's more Python libraries, and they're generally better maintained and better documented.
- Python has a better interface to C.
- Python is more popular and generally more supported by third parties.
- Django/Flask
- There is comparatively little Ruby activity outside of Rails and a few cybersecurity projects.
I really do not like Python. I think it's really inelegant. But it's a better tool for getting my tasks done, due to the above reasons.
Didn't this eventually become what is now pathlib (which I am a big fan of) ?
Looks like you are the author of PEP 355. Well, we got pathlib in the end. It's not that bad.
For a long time, the official Windows Python distribution was overshadowed by ActiveState's, called ActivePython. That included more Windows-specific packages such as win32com, and the very capable PythonWin IDE from Mark Hammond. That was my go-to Python around 2000-2005.
ActiveState was also notable in the early 2000s for hosting the Python Cookbook, the main repository of useful Python snippets and scripts. This was long before PyPI, StackOverflow and Github.
I'm sure this is less of an issue when you work with it every day and are familiar with it, but I always dread seeing python in the requirements for something because it means the odds of it "just working" on a random system are probably not great. Anybody else have this experience?
The python modules eco-system lead to the stake change. Scikit-learn, Pandas and Numpy made it so useful for visualisation, research, old school modelling ML. Writing and saving files was simple. Making your own module took 2 files with 4 lines of code. How easy.
After establishing use cases in Python 2, which already allowed a lot of C code in practise for speed, Python 3 changed everything with a simpler language that makes it clear what is normal and weird. You might dislike [:-1] at first, but you definitely know it's weird compared to other languages, so you can know what to search for. Not true of abstractions in some other languages like Ruby, for migrating devs.
Then Python caught with Tensorflow/PyTorch a real wave of being the place to go. Kaggle involved 100,000s all coding in Python for data science in the latter half of the 10s. It did this at the same time as the LAMP stack and LAMP pre-installed VPS running cPanel were dying to React/node.js and PaaS approaches on the one hand, and big cloud providers on the other. So suddenly, there was not an easy default 'nix environment with PHP to rely on being available so easily, and adding python to an existing server is super easy (and Flask/Django easy to grep), making adding a backend for ML or whatever, very easy too. Ruby wasn't even on the playing field for many of these use cases.
I think a last small impact was that Ruby was misused where shell scripts could have worked. Many people made Ruby cli tools for their internal team, when shell scripts would have been fine - this frustrated some of their peers away from Ruby. There is no difference from Python here, but I just noticed it more.
For the generation who used matlab in grad school and then abandoned engineering and science to become software engineers, it provided a good soft landing to transfer skills.
Ruby is too different; too many symbols and idiosyncrasies inherited from Perl, Smalltalk, and created by itself.
That is the root reason why they diverged and Python ended up with the scientific ecosystem.
This is further evidenced by Ruby’s popularity only shooting up with Rails, when 2005 web 2.0 attracted lots of non-CS people to come into the field with no prior C-based experience, so they learned Ruby, html, and css fresh.
And then lots of things were built on top of Numpy - image processing, reading GIS raster data, scipy, pandas, etc etc - and they're all trivial to combine because it's all just Numpy arrays.
Python also had a very friendly and approachable community from the start, and great docs, while Ruby had its documentation in Japanese only for some time.
Django is also top quality, imo. Similar to Rails. But it always seemed Ruby was only good for Rails, whereas Python combines with everything.
So as usual, it's not about the language, it's about the rest.
However, the significance of both declined with the expansion of high-tech options (Spring, Go, Scala, Node.js) and the expansion of low-tech options (Firebase).
So today the popularity of the backend frameworks of each language are less important.
Maybe it used to, but seems a lot more people at least searches for Django pretty much everywhere except US, Canda and Japan.
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
StackOverflow agrees. [1]
[1] https://insights.stackoverflow.com/trends?tags=django%2Cruby...
Before then Zope (on which the popular Plone CMS was built) was probably the most widely used web framework in Python. But there were many, many others too.
You can also do things like adjust the settings defined in your settings.py file to use a different url conf programatically based on environment variables. It is just python, after all.
My memory is that, at least outside of the web/RoR world, Ruby at no point as popular in the US as Python. Lets take, say 2005 as a point that Ruby was really gaining popularity due to Rails: at this point I was already seeing internal tools that previously would have been written in Perl being written in Python.
Python just seems to have maintained a certain momentum, and I'm not sure why, but if I had to guess:
1. The syntax is almost a dead-ringer for pseudo code. The first time I encountered Python, I fixed a bug in an open-source project having never seen Python before. I recall two different CS programs switched to Python from Scheme for exactly this reason.
2. It was designed to glue C together. Other languages were too (TCL and Lua; Perl primarily interfaced with the outside world in the same way shell does, with pipes).
3. A kitchen-sink approach to the standard library helped it a lot for the first 20 years of its existence. CPAN was sui-generis at the time for installing libraries, so the more you could do without relying on 3rd-party libraries, better off you were.
1: https://en.wikipedia.org/wiki/Eggdrop
You could kind of write Java in Python, and thus a certain kind of enterprise techie couldn’t dismiss Python as “just” a scripting language.
Perl like VisualBasic had a well deserved reputation for facilitating atrocious hard to debug code, and it was this reputation more then the lack of OO/XML support that led both of those to fade back into the realm of forgotten memory and business critical enterprise applications that nobody dares to touch.
Google was known as one of the most academic engineering companies, in the 00-ies.
Every Perl code base I've seen, or inherited, has been a mess. My favourite was a bunch of utilities all written by the same person who never did anything the same way twice. Each utility was like an entry in an obfuscated 'C' contest.
I used Perl to build my first web application at LONG time ago. That project is included in the list of Perl code bases I've seen that were a mess :-)
Rust doesn't even sport 'Class'
It did take a while for the wider Perl community to embrace OO, though. There were a lot of Perl programmers who weren't into lofty paradigms. Plenty of Perl programmers weren't fully sold on the idea of breaking your program into functions.
I loved Perl, but it had a culture of doing things in N different ways, too many shortcuts, and you ended up with incredibly tiny scripts which were unreadable -- even to the author -- a month later. This wasnt practical for business use in the face of more consistent code from Python
There were so many "it can't possibly be that easy, but it is!" moments.
Let's write a function to add five to a number:
OK. So, can I pass that function as an argument to another function? What? That worked?! And there was zero additional syntax, you just... do it?After a seemingly endless list of happy discoveries like that, I seriously rethought my idea of what programming languages could be, and ought to be.
A few years from now, when researchers look at mental workload when writing/reading software, we will have the data to prove that Guido was a Neuroergonomics savant.
I have never found Python as nice to use as you seem to have, but Ruby always fit like a glove. I’ve written Python since 1999 and I still would rather use almost anything else. It’s so labored to do anything complex. You can build worlds in Ruby in the time it takes you to align indentation properly for a single class in Python.
Here's the C version of it:
It's still manageable, but not nearly so simple.Even Perl doesn't let you escape having to consider pointers and references:
Why do I have to remember to write `\&addFive` in Perl, when Python doesn't require it? Why do I have to write `$func->($value)` instead of the normal `func($value)` in this case? Why do I have to write `$value` in the first place? That's rhetorical: I know the answers. Still, this was the kind of thing that instantly won me over from Perl to Python. It's not that I could somehow write things in Python that were unwriteable in Perl (or C, or assembler, or ...), but that Python let me concentrate on what I was trying to say instead of how to say it.In fairness, the equivalent Python code with optional typing is also more verbose than my original, minus the pointer stuff:
The key word there being "optional". Python lets you add that if you want to, but you don't have to. And note that the underlying syntax is identical if you delete the annotations. If you opt in to using them, you don't have to alter the code you're annotating.I do wonder how much would be different today if not for the Monty Python gags in the documents.
When I’m appointed Lord Emperor, we’ll all upgrade back to Lisp.
Ruby on the other hand encouraged cleverness like what you wrote.
I think ruby faded for the same reason perl did. It is cool to write code, but once it's time to maintain it, especially after the rock star who wrote it left, it sucks.
So we should optimise languages for users who are not prepared to familiarise themselves with the language? How is this more complicated than its commonly-used Javascript equivalent?
You see when written in a language in which lambdas are first-class citizens it doesn't look clever at all so maybe Python's sad implementation of lambdas and its anti-fp culture could be at fault?This is the big one. You look at it, and you think you know what it's going to do. The indentation rules also means things look predictable rather than being a mess of brackets.
I wanted a language that I would come back to and still understand what I was trying to do. Ruby looked like its spirit animal was perl.
But I'll add Ruby on Rails and a lessor extent Ruby was pushed by hipsters hard and people who didn't program but were internet explorers.
Python just was. You'd never have not considered it a language.
I always thought having Python 2 and 3 held it back a decade. The fact it won despite that means to me it was never a contest.
People care delivering features rather than design and build the best in class architecture.
I wish javascript adopt the same python philosophy, rather the actual "spaghetti mess".
The main thing that has led to the decline of Rails is the rise of no-HTML-just-an-API backends. Your web frontend development stack is more likely nowadays to be, first you pick between React or a similar framework, and then the backend just sends API data and doesn't mess with HTML. This makes for better websites, and it makes joint web and mobile development easier too, because you're going to have to build that API anyway for your mobile app.