Ask HN: Why Python over Ruby?
I would like to understand why Python is so much more popular than Ruby. Much of the software I've seen supports Python for scripting (e.g. Miro, OpenMoko, XBMC/Boxee), and people don't seem to care so much for Ruby. At the same time, people agree that Ruby is great for writing DSLs.
I don't want a flame war or religious arguments. I would like to understand what made Python win in this space. Thanks so much for commenting!
197 comments
[ 3.5 ms ] story [ 218 ms ] threadI wouldn't say Ruby has lost just yet.
Regarding libraries; you are right. Ruby has a lot of code out there, but much of it is in random repositories maintained by random people. Hopefully this changes.
However - "easy_uninstall scipy" REALLY needs to work!
JRuby FTW.
Yes, there are downsides to sitting on the JVM, but for anything other than one-off scripts, or where start-up speed is really important, JRuby gives the best of both worlds[0]: Ruby syntax with JVM libraries.
[0] Clearly if you do not care for Ruby syntax then this is not a win. I believe, though, that JRuby is more advanced and stable than Jython. But the Jython folks are quite capable for continuing to kick ass, so that will improve.
http://shootout.alioth.debian.org/
Having found Python, I really don't feel a pressing need to learn another scripting language. Instead I'm working on Objective C.
Ruby borrows some stuff from Smalltalk. You know what other language borrows heavily from Smalltalk? Objective-C :)
I'd love to learn Scala (after being a Haskell and Ruby fan for years) but finding the time is incredibly difficult...
It's also, to me personally, a lot faster to whip something up in Python than in Ruby, even when I knew them at about the same level.
Python became popular with Linux and open source developers before Ruby did, and has had slightly more time to develop a nice set of libraries to do just about anything.
The online Python documentation tends to be pretty good. When I picked up Ruby a year and a half ago, and I tried to find the documentation, people generally pointed to the pickaxe book as the de facto documentation.
Although I've been using Ruby on windows the last few weeks with Ruby Shoes from _why(normally use for unix scripts or web-dev). It's pretty nice (although a little rough around the edges as it's under heavy developement).
When you install shoes (the latest version anyway) you get the GUI tools, ruby gems, and sqlite, and a ruby interpreter, all neatly packaged. And there is a whole load of items I havent looked at yet. It's fun.
Nowadays I work on Kubuntu, and maybe things have changed, but I've no bad experiences with Ruby on Windows.
Come to think of it, we, ruby programmers, don't really pay our dues. 1.9.1 has been out since January/February, and nobody bothered to package it for OSX, Windows, or Ubuntu.
Thanks for bringing this issue into the light.
I get the impression that there are more 3rd-party libraries in Ruby, so it is easier to get web code up and running with ruby.
Django is the most popular single framework, but at least as many people prefer to roll their own based on various modules. Some of the most popular backbone kits would be werkzeug, cherrypy, webpy, pylons. Then there's literally dozens of template languages (jinja, genshi, cheetah, to name a few) and at least three mature ORMs (sqlalchemy, storm, sqlobject) to choose from.
So, while I have no idea about ruby libraries I can assure you that in python-land you get to choose between at least two mature options for pretty much any web-related task.
For instance, Haml and Saas are pretty widely accepted by Ruby web developers, whereas Django templates are very popular with Python web developers precisely because because they are close to straight HTML. Ruby developers (like Ruby itself) readily adopt good ideas from other languages, including Python (rack from wsgi, rip from pip, merb slices and rails engines from django apps), while anything that resembles anything from ruby or rails, like some Pylons components, gets criticized by many python developers. It's noticeable with version control, too, as svn is still very widely used by Python developers whereas Ruby and Ruby/Py developers moved completely to git and hg over a year ago.
Python is such a large tent that it's quite inaccurate to say that "the Python culture" lacks a sense of experimentation and adoption of new tools. What you might be getting at is the fact that there are already so many existing libraries in Python for doing most things that there's not a lot of public reinvention of wheels going on.
It's not remotely as universal as it was for Ruby developers. When working with Python you still can't go a day without hitting an svn repo, but with Ruby you'd easily not touch one for months.
"But I don't understand what VCS choice has to do with language culture."
A lot, and I already described it. Ruby developers and the Ruby language overall are less conservative and more open to dramatic change than Python developers or the language. Each model has its benefits.
"'Python is such a large tent that it's quite inaccurate to say that "the Python culture'"
It's a large tent, but the common thread is Python and Python's principles, and they define the culture.
"there are already so many existing libraries in Python for doing most things"
But individual developers don't do most things, each works on certain things. Python has lots of libraries, but that doesn't mean it's the best choice for any specific job. As a web developer, there are a huge number of Python packages that don't matter at all in that domain. If sheer number of libraries mattered, we'd all be using perl.
They're both good languages with good communities though. Each has a few advantages and disadvantages, but they're similar enough that if you know one you should probably stick with it and be happy, and pick something farther from the tree as your next language (Erlang or Scala, say).
Reality seems a bit different to me:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
http://bitworking.org/news/413/ruby-books-sales-a-retrospect...
Although it's worth noting that Ruby too, runs on GAE using JVM based implementation (JRuby).
I'm generalizing to some extent, of course, but these are the things that I and other developers I know associate with Ruby (including many who's startups are built on it). I imagine as the language and community grow and mature they will shed these associations and hopefully create a language worth taking seriously. They haven't done that yet (strictly in my opinion).
For instance?
I call bullshit, sir. Ruby is objectively less strange and more consistent than Python. Some has to do with the fact that Python is older - hence has more baggage to carry. A lot of it, though, just has to do with poor/missing design choices. Specifics?
- ruby 'block' passing convention is much cleaner and more powerful than python's 'for'/iterators.
- python's global functions are stranger and more ad-hoc than Ruby's strict object-orientation.
- ruby's mixins > python's multiple inheritance
- python underscore (and double underscore) naming conventions to overcome simple language features
Don't get me wrong: i love python - but primarily because of the faster execution and larger community - not because of the language itself.
Python's iterators are more usable in many situations than the Ruby block system. I can return an iterator, stick it in a variable, call another function with it that returns another iterator, and so on.
Python's classes also seem cleaner and less magical than Ruby's. For example, a method on a class is just an attribute that happens to be a method. Much more intuitive than Ruby in my opinion.
I'm also fond of Python's idea that "There should be one-- and preferably only one --obvious way to do it".
I agree that Python does have its fair share of strangeness, but that fades away with time (you don't notice it).
Personally I find blocks far more intuitive than Python's iterators and generators, but that is a subjective thing.
WRT Magical Classes, I'm not a fan of everything being stored in a dict. It seems grossly under-engineered to expose the underbelly as a basic "dumb" object; at the very least, it should've been a "Class Metadata" object with attached support methods to make it easier (safer?) to inspect or update.
And lastly: there is NEVER just one way to do it!! Witness the confusion n00b's feel over the join() method: ",".join([LIST]) where the more intuitive would probably be [LIST].join(",")... but if you MUST have join() in the string module, why not support the latter as a redirect to the former?
Seriously: this sort of dogma can make certain kinds of algorithms very messy to code.
However, my biggest beef with Python is that I seem to have to write a metric buttload of boilerplate and end up with something very Java-esque... <sigh>
I completely disagree with having to write lots of boilerplate and java-esque code. I've written huge amounts of Python, and seeing Java after that really made me wince. What does Python lack that makes you feel you need boilerplate?
I don't think the one-way-to-do-it thing is that dogmatic, really. It does make code nicer when you don't have to be aware of various aliased methods, and there are less ways of making identical code look different.
Having ploughed through several tutorials, I did not find Ruby particularly "elegant", or its syntax particularly obvious. Much of it seemed ad hoc, thrown together, in particular when there were several different ways of doing something, and it seemed to be the philosophy of the language to provide all of them. I did not find its constructs as intuitive and natural as claimed, trying out simple coding examples proved as frustrating when things didn’t do what you’d suppose they’d do...
(http://www.bitwisemag.com/2/What-s-Wrong-With-Ruby)
I actually gave Ruby a shot, going through the interactive tutorial on http://tryruby.hobix.com. I couldn't do it very long, however, because it was completely ridiculous. In what world does it make sense for hash keys to double as string grep? For instance:
will replace the first instance of foo in my_string with bar?! WHY?! I can stick an exclamation point on the end of method calls... to signify mutation? WHY?! What twisted logic allows one to rationalize multiplying strings like: yet throw an exception for: It makes absolutely no sense! And why would an integer have a method for converting itself to a string? Or an array? I found so many things in Ruby that made me think, "Okay, superficially that's really convenient and sorta cool... but it makes no sense and it is absolutely counter-intuitive. And I feel dirty using it, even if everybody is doing it." Some people, I assume, find Ruby to be "elegant" for the same reasons I find it to be "an abomination."Firstly starting with my_string['foo'] = 'bar', this is a syntax that is used a lot in Ruby for anytime that you wish to recover a subset of a collection - you can use it with a Dir object for example to recover a subset of directories/files, or in the case of a hash, to recover the object stored at the key. The thing is that you need to think about it as being a subset operator, rather than an index operator.
The exclamation point at the end of a method name has no syntactic meaning - it is simply a naming convention used by the standard libraries to indicate when the method mutates the object or not. Same same for method names ending with a question mark, it's just a convention to indicate that the response will be a boolean.
As for the whole "5" * 2 vs. 2 * "5", I must admit to not understanding where you're coming from. I don't see how you could expect any other kind of behaviour from an object orientated language. Personally I don't like over-riding arithmetic operators for non-number types, for precisely this reason, but hey, some people like it, so why not?
Integers converting to strings? I think every language has that no? I mean there's always something like: sprintf(myStringPtr, "%d", myInteger); or cout << myInteger;
etc etc
By making this a standard method on all classes (to_s), Ruby makes it really easy to dump a class to a serial format, which is very useful for debugging, as an example.
I get the impression that you simply didn't spend enough time with Ruby to come to understand its idioms, in which case, you're not really in a position to effectively criticise the language...
A lot of Ruby's conventions simply scream "ambiguity" to me. A "subset of a collection" is extremely ambiguous; if there is more than 1 foo in my_string, does it always get the first? How do I get the rest? my_string['foo'][2] or something? I can't even intuitively make something up which makes sense to me. Perhaps there isn't a way to get the others, which I suppose would be in line with Python, which doesn't supply a string method to find all occurrences at once... but how do I offset it?
I can see where standardized methods like to_a can be more convenient, but they also open up the possibility for unlimited ambiguity. What does Foo.to_a do for your Foo class? It could do anything! There's no way I could rely on these methods to do something across the board unless I know your class conforms to some Interface (do Ruby folks use/have Interfaces?). In Python, if I do
Then foo is now a list. I always know what I'm getting. I always know what int() is going to attempt to do to an object, etc.Yes, there's no way to get the other matches using [] as far as I know, it's just a generalization of being able to pass various types to it; Fixnum, Range, Regexp.. I don't see the harm in doing something with String too. If you wanted to extract multiple items, you'd use something like String#scan, or if you wanted to do a global replace, String#gsub, which can also accept a code block to perform computed replacements.
I can see where standardized methods like to_a can be more convenient, but they also open up the possibility for unlimited ambiguity. What does Foo.to_a do for your Foo class?
As of 1.9, it does this:
In 1.8 it issues "warning: default `to_a' will be obsolete".In Python, if I do `[foo]` Then foo is now a list.
You do the exact same thing in Ruby, though if you're wanting to cast your argument like the old to_a did, you use Array(), which won't turn [] into [[]]. If you want a number, Integer() or Float() will raise an exception if they can't give you one.
Well yeah like others have been saying, python is more attractive to new users is probably partly why it's more popular. You don't need to work as hard to understand its idioms, it's more readable by newbies (by anyone), etc.
Python has a __rmult__ method. If you do A * B, first it internally calls A.__mult__(B) then if that raises TypeError, it tries B.__rmult__(A). It's pretty elegant, I think. For Ruby, it wouldn't look as nice to do A.r* though, I guess, but it would be a nice bit of functionality.
You're calling a method on a string, so you got the string doubled. Seems to make sense to me.
Obviously in this case the order of the arguments matter.
It's not obvious in terms of intuitiveness, no. Why not extend the Integer class to know to call mystring's * method when their order is reversed? That would be intuitive.
You need to remember that EVERYTHING is an object, there are no basic/literal types at all; in this case, "5" is really just syntactic sugar for creating a "5" String object, 2 is syntactic sugar for creating the "2" Integer (Number?) object, and the " * " operator is syntactic sugar for the " * " method of the "5" String object == ' "5".times(2) ' (which is similar to Perl's ' "5" x 2 ' construct).
The String class supports a " * " method which creates n copies of it's string value, and concat's them together into a new String object, but the Integer class does not.
Many "basic" objects have explicit conversion methods, but will also frequently support implicit conversion where it makes sense.
[1] As I wrote two years ago: http://www.halostatue.ca/2007/03/17/whats-wrong-with-bitwise...
You know that under the covers in Python str(1) works by calling (1).__str__(), right? That's why you can make str(my_custom_class) work.
It's difficult to accept your rational argument when you include stuff like this.
Ruby developers (Rubyons?) were renowned for typical Japanese self-effacement when it was becoming popular, which I think was some of the appeal... I guess what goes around comes around...
:)
And while it certainly isn't a fault of the language, it definitely influences it usage for some people.
That's a decision you make for yourself, not an absolute truth.
In any community of size, you get good seeds and bad seeds. Python is not immune to this.
Looking at some of the drama and prima donna action in the Rails community (from a distance) just made me sad and grateful that my corner of Python (scientific computing) doesn't have those sorts of issues.
And yes, a lot of us pythonistas view him with suspicion.
During FISL, a couple days ago, I witnessed something that really bothered me. It was a presentation comparing Rails with Seaside (which is, by itself, like comparing racing cars with subarines) and the arrogance of the Rails guy dismissing Seaside, Squeak and Smalltalk was very uncomfortable.
It seemed the room was too small to fit all the egos inside it.
I considered staying until the end and asking a couple questions to demolish the presenter, but I decided it would not be worth it. His belief on the inherent superiority of Ruby and Rails over any other language and framework, past, present and future, bordered on the religious.
If Rails weren't around, it would be much easier to enjoy Ruby without having to use it in isolation. Then again, a whole lot of people wouldn't have gotten into it in the first place.
Ruby lived fast and died young. If you don't want to use Python, learn Haskell.
How can you say that a language with active development and an active community has "died"? Seems like an odd conclusion to make, IMHO.
And it is really easy to enjoy Ruby without Rails. A friend and I have been doing it for a couple years now.
Sweet! I am making a living using a zombie, undead, from-beyond-the-grave programming language!
I better hook up that USB Ouija board and get coding.
Zope 3.x (Plone runs on top of Zope 2.x) is a very nice application server. I wonder if it would be possible to make it work seamlessly with things like Hadoop instead of ZODB.
How so? It's mot like Python is 10 or 20 years older, so how do you determine the "far more" part?
And of what value would this difference in maturity be? COBOL is "far more" mature than Python. Is that a big win for COBOL?
Once a language reaches some reasonable age and general wide-spread usage, points about maturity seem silly.
(On reflection, I suspect you're just trolling.)
On the flip side, I am not aware of any significant impact of Ruby in commercial development that is not web-driven. When we bid on projects and talk to prospective customers, we're typically making a case against Java and C++. I can't recall a single instance where someone seriously asked us about Ruby. (We've had more inquiries about KDB and K, that abomination of a language.)
So, just my $.02 as a scientific software developer.
For example, this from Wikipedia:
Has some funny brackets and pipes. In Python, it's much more familiar to C-ish folks like me:PS I'm not a Ruby zealot, and Python is a great language
Zen of Python: "There should be one-- and preferably only one --obvious way to do it."
Sure, there are other ways to do it in Python, but it'd be frowned upon to use something like 3.upto(6) rather than a standard range() that everyone is used to. Readability matters.
Note: I used Python daily at work and for open source projects. I also use Ruby for open source projects. I like them both.
This makes me curious how much more frequently range is used than xrange and in what situations it's preferable.
However, Python's TOOWTDI comes to mind. Not that it's quite true, but probably closer than with Ruby. I guess one could debate whether TOOWTDI is a good thing -- but I reckon Perl is the argument as to why it is a good thing.
"Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language."
When I first saw this, I went "Google? Whoa. I gotta check this out" :)
That's one cool list
I had a similar experience in '02 or '03. Then I quickly recognized that Google's decision to concentrate on Python, Java and C++ doesn't have any bearing on my companies' choices, especially since some major factors in Google's decisions (eg, dealing with a very large number of internal developers) just don't apply.
http://en.wikipedia.org/wiki/Cargo_cult_programming http://weblog.jamisbuck.org/2008/1/7/never-ever-cargo-cult
And strong company backing: Google has have hired some of the core Python developers, and some of its infrastructure is written in it... Flumotion with its streaming media (although codec stuff is mostly gstreamer, but most of the networking stuff is in Python)
And the final straw - Python just seems to be a bit more beginner friendly...
The main reason was when they were standardising on the core-languages they could support, Python was enormously far ahead cf. the competition, so it was an obvious choice. And now, with all that code investment, you do NOT want to start again. And if you have the money, of course you'd be interested in hiring the best developers for your code-base.
Likewise, I believe Python 3000 is unlikely to used in Google for the forseeable future, due to that same code investment. I don't think Python 2.6 is fully supported, either...
I don't think "a bit more beginner friendly" is truly accurate. Most beginners will look for doc's and books, and for a good few years, recently, there was a dearth of good Python books while there seemed to be a new Ruby or Rails book every month, including several allowing you to d/l them for free.
I have to admit that I used to recommend Python to beginners for a long time, as it helped them avoid developing bad habits with the other equally popular "beginner" PHP and Visual Basic languages. These days, it's a toss-up.
If the person talks about writing web-apps, I'll tend to recommend Ruby and Rails as it has earlier ROI for a beginner, therefore a lot initially more satisfying.
See: http://stackoverflow.com/questions/754301/what-programming-l... http://stackoverflow.com/questions/923225/does-google-use-py...
Nearly all of the installers and packaging formats and management tools in Linux have Python APIs.
Edited as I wasn't clear the first time round: I love Python's wide variety string methods, and the emphasis people put on these rather than using RegExs all the time (sorry, I have more Perl and less of a Ruby background). Looking further it seems there's Ruby equivalents of most of my frequently used methods.
I love etrees in the standard library. People who use regexs for dealing with tree structured data are mental. Again, perhaps a Roby fan might enlighten me if there's a similar data structure in Ruby, I wouldn't be surprised.
What do you mean? Of course Ruby has a String class and plenty of methods on it, but I'm not sure if that's what you're talking about.
Ruby comes with an XML library standard, sure, but it's pretty bad. In my experience most people use competing libraries, of which there are several high quality options. You can get a walkable tree from the core library but you'd be better off with one of the superior third-party libraries like hpricot or nokogiri.
(edited badly written original)
The behavior I'm referring to is loading XML into a tree shaped data structure, so you can reference particular branches when seeking or adding content, and not have to think about about tags (well, once you'veran it though BeautifulSoup or a similar cleaner).
I am not really familiar enough with Python to say for sure but from what I know, XML libraries are probably superior on the Python side - in fact most "enterprise" interoperability libraries are probably better, or at least more mature. The situation on the Ruby side is improving rapidly, but given its history, yeah, many things like that are probably a little behind. Ask again in a couple of years!
The flipside of this, though, is that everything in Ruby is currently in a state of flux. The "winner" of the libraries is constantly changing and the rate of progress is actually quite staggering. There's excitement, momentum and willingness to embrace new ideas in the Ruby community that seems to exceed Python's.
So yeah. If you want stable, mature libraries that you can rely on for the next 5 years, Ruby is probably not the choice for you right now. If you want, however, to constantly live on "the edge" and see, say, 5 competing interfaces to the latest DB come out within days of its alpha release then Ruby's the go.
This is all fairly minor though - they're both great languages with great communities, I don't get all this "A vs. B" nonsense. There are certain libraries in Python that I wish were available in Ruby. There are certain libraries I like in Ruby that I know are not available in Python. My advice to a novice would be to choose the one whose syntax they prefer.
It is a stinking pile of shit.
Gets to the point where other libraries are so common that they may as well be in core, though. I wonder if there's any rubygems installation anywhere that doesn't have hpricot.
No, not really.
Some do, I'm sure. I've had great success with it when I needed it.
But more seriously Python is a growth like Javascript. It has grown and adapted to every change it has been required because it has a very rapid iteration time and is great for wrappers to core C. It is clean and maintainable.
For this it has made huge inroads to system administration, game development, tool plugins, web development, command tasks and everything else. I have yet to have one instance where there weren't numerous libraries for every task. Even if you don't want to use a third party library there are many examples of how to do it.
Python is really at it's core many things. It is a functional language, it is an OO language and it can be procedural. It can wrap intense lower level libraries or port in a C extension for speed. The same code you wrote for your desktop api, can be used in a desktop app, a service, website, a web service, a tool plugin, at the command line or any way you need it.
It can float like a butterfly and sting like a bee.
Like Javascript, Python is based on a core few types, lists and dictionaries (objects). All the languages that seem to permeate like viruses have this basic computer science fundamental. It just is as simple and clean as you can get. Ruby also has this but it came a bit later.
And finally, it is named after the great Monty Python.
end
Ruby
- follows TIMTOWTDI
- Mutable strings etc.
- has a greater emphasis on code generation ("meta")
- VM's are much slower than Python (there is no Psycho etc.)
- emphasizes code clearity and readabiliy (human cycles are more important)
- Libraries are much less mature
- ...
The lists of differences could go on forever. A comparsion and "why" is difficult. I think they are too similar and the people are too polarized.
A language is a tool to solve a particular problem. In the case of Python you have higher momentum of the community and the switch from C/C++/Java to Python is often easier than to Ruby. (Wild statement of me with tests from a sample set of 2 test subjects ;) )
Probably the best characterization I can come up with is. Python is already on this "Enterprise" trip where companies use it a lot and so forth. Ruby has some interesting companies pushing it (Twitter etc.) but is not compeletely there yet, it still has more "hacker" and "monkeypatch" feeling. Oh wait, we call that "ninjapatching" in Ruby ;)
Python is not a radically better choice in terms of speed (and hell that's true even w/ 1.8. Sure Python's faster, but we're not talking orders of magnitude here).
You might choose Python for exactly the same reason; e.g., I wouldn't use Ruby on teams with >2 developers, especially in Google. Python is more straightforward but at a (small) price of freedom.
Example: you can rapidly prototype in Ruby using blocks and extend basic classes (even integer) using monkeypatching. I was fascinated by this, yet I wouldn't monkeypatch when working with other people so that advantage goes out of the window.
I can READ other people's Python code with greater ease than Ruby, Java, C#, C++ or even C. At the end of the day, the quicker I can assimilate library code the quicker I can use it well and the quicker the module gets completed and fully tested. Of course, with Google and Eric Raymond raving about it, the confidence factor increased further.
It is true that Ruby gives you a lot of rope. People with good design sense appreciate that your code should not be too clever.
Just which Ruby community is this? None that I associate with, that's for sure.
To the people who voted the OP up; is it because of your own first-hand experience with other Rubyists? For all I know there are clusters of Ruby coders who encourage obscurantism, but I've not encountered them (though I've been part of debates over just what constitutes "obscure").
http://www.google.com/search?q=python+ninja
http://www.google.com/search?q=python+rockstar
<pre> Weighted use of Search Term Hits Search Term Hits obfuscation
"obfuscated perl" 1390 "perl programming" 164000 0.85% "obfuscated python" 234 "python programming" 157000 0.15% "obfuscated ruby" 269 "ruby programming" 133000 0.20% </pre>
If I use the word golf, I get: <pre> Weighted use of Search Term Hits Search Term Hits golf
"perl golf" 1780 "perl programming" 164000 1.09% "python golf" 171 "python programming" 157000 0.11% "ruby golf" 547 "ruby programming" 133000 0.41% </pre>
This is of ccourse, the same statistics that fueled the last financial meltdown :-)
Why limit the discussion to Python and Ruby? Why not include PHP, say? Why have Python and Ruby "lost" to PHP? What about C++, Java and C#?
Heck, VB is still more "popular" than either: http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
I compared to Ruby, because that's the language I would choose for scripting, based on the ability to create nice internal DSLs.
When NOT talking about embedding or scripting, I'll probably take ruby.
Interesting. I was a Perl hacker, and Ruby was the obvious choice for me.
After their pretentiousness, their arrogance, and their vociferous obnoxiousness, I find their misuse of this once-widely understood term to be their most annoying attribute. It seems like not a day goes by without some eager Ruby programmer hacking together yet another block-based API that kind of, sort of looks like Smalltalk if you squint enough, uploading it to GitHub or some similar site, and then slapping the "DSL" label on it, because Ruby, apparently, is just too cool and powerful a language to have mere "libraries" or "APIs."
Ruby does in fact both have libraries and APIs (hyperbole aside). But none of what you've described is a reason why Python has become more prevalent than Ruby. This is just your personal bone to pick over nomenclature used by the Ruby community.
Rails is not the only piece of software in the Ruby community, and definitely not the most well designed (although it too is being improved significantly both in consistency and cleanliness in the push to 3.0).
Granted most things people call DSLs frankly are not, an internal DSL is a well known concept and repeatedly implemented in a lot of languages.