The python/ruby thing seems to be at an interesting point. Python as a language has a bigger mindshare but none of the python web stacks has close to the adoption that rails does.
As far as I can tell there seems to be a lot more peripheral innovation in the ruby camp though, particularly in testing tools. Are there python equivalents to rspec, cucumber, factory_girl/machinist, shoulda, passenger, haml, webrat etc?
I'm not sure about the framework adoption thing, Django seems to be the major Python framework. I'm not saying there aren't others, but most newcomers to Python web dev quickly realize that Django is the name of the game.
That's because Python is actually used extensively in the West outside the context of web development. Ruby really isn't. Rails became popular, and people decided to learn Ruby so they could use Rails. Most people who choose Python web frameworks do so because they are already familiar with Python.
But I agree, I learned Python because it seemed like a great language, and learned Django because I was moving into web dev after years of other work with Python. I don't believe I'll ever pick up Ruby for anything other than learning Rails (and I doubt I'll even do that, since Python is so similar).
Just take a look; the django bar is not even a bar, more like a square. Rails seems to have a 40:1 edge over Django in popularity.
The other thing you will notice is that India is where Rails is most popular; but try to pull back the timeline slider and play with it a bit. See how different countries discover rails at different times but soon after lose interest? Except for India, it stays popular there.
I'm not sure what your link is trying to show, actually.
But note that most people searching for Django will use only the name Django, whereas Rails is often called "Ruby on Rails", meaning searches for "ruby and rails" will naturally tend higher than "python and django". Again, I'm not sure I understand your point, so I don't know if this means anything.
This is an answer to a question that grasshoper is not asking: he claims that Python is used extensively "in the West" in contexts other than web development.
Comparing search traffic for django/python to ruby/rails has nothing to do with this.
Django is arguably the most used Python web stack, but it's also a much more controversial choice than Rails is in the Ruby world. I hear "you'll outgrow Django really quickly" a lot; whether that's true or not I can't say since I've never used it. Also, there seems to be a lot more choices for web frameworks in the Python world: Django, Pylons, web.py, Tornado, Flask, CherryPy, Zope etc. I'm not sure if this is the case in the Ruby world. All I ever hear about are Rails and Sinatra.
Ruby allows developers to make really nice DSLs. (Domain Specific Languages) It makes sense to me that there would only be two major frameworks. Rails fills the need for a batteries-included framework and Sinatra is the a light weigh, nothing included framework. Both have expressive enough implementations that the community doesn't build their own frameworks.
Python doesn't make as pretty code for a DSL which makes it more likely to hit pain points in expressing what you want. Then you end up with a fragmented community around these different pain points.
Second theory.
People start using ruby because of rails. If rails is too heavy, they move to sinatra. Most of the people using ruby can't be bothered to write their own framework.
Most people using python learned python before web development. They are more experienced in the language and used to doing their own stuff. They try out different frameworks and if they get disgusted enough with them they create their own.
Disclaimer:
I'm a ruby guy. I used python for two years before learning ruby and then rails. These are only theories. I probably look at ruby more nicely than I should but I tried to be somewhat objective.
Can you explaint to me what all these little DSLs are useful for? I have heard this being presented as an advantage for Ruby before, but can't really think of many use cases for DSLs (apart from business rules).
> Can you explaint to me what all these little DSLs are useful for?
Writeability and readability. The ability to bring in domain experts which have no knowledge whatsoever in programming as well.
> but can't really think of many use cases for DSLs (apart from business rules).
Any domain-specific knowledge/data may be encoded as a DSL, and benefit from it. The rules of your business, the URL mapping of your framework, the GUI layout of your application, the steps of your tests, ... In fact, they often are (in WPF, XAML is used as a GUI definition DSL; Ant is a domain-specific language for building applications, so is Make).
The great advantages of the likes of Ruby, however, is that you can build DSLs in the language itself (you don't have to build your own compiler and translator from DSL to language), which rids you of most of the complexity and limitations of usual DSLs, and lets power users realize that there is a full-blown general-purpose language under the DSL (and use that power when they need it).
There are actually a bunch of Ruby frameworks (ramaze, rango, waves, padrino, camping, halcyon, to name a few off the top of my head), but it seems Rails and Sinatra meet the needs for the vast majority of Ruby web developers.
Yeah that may be true. I wonder how big the installed base of all those python frameworks is compared to rails. Hard to estimate I suppose.
The ruby world seems to focus its innovation around the major framework whereas the python world seems to be experimenting at a more fundamental level.
The biggest issues with Python are speed and the lack of typechecking.
Interesting that they took this bit of wisdom away from programming in PHP.
I say this because I've never heard anyone consider a lack of type-checking as an issue when considering Python. It's a feature. You either need type-checking or you don't. I suspect that the Quorum engineers didn't need type-checking, so I don't understand why the felt the need to consider it an "issue" with choosing Python.
Spare yourself this yammering rant. They chose Python because that's what everyone else at the company was cool with. End of story.
Python tends to raise errors for type mismatches, which forces you to do the work to avoid them or handle them. PHP usually does something nonsensical instead, which probably screws you over--but you don't necessarily notice unless you are independently sanity-checking its results.
That's not really correct. In general, nobody needs type checking (it's not like there's any actually done where it would be needed the most), but it's "free" error checking. Always nice to have.
But it is a feature to balance against others.
Anyway, considering how weak the type systems of "industry standard" languages are as opposed to Ada, or MLs, or Haskell, the common type-checking trope is mostly a huge joke.
Type checking has many benefits other than making assertions about value types. It can provide hints to the compiler and has proven useful in some models of parallel computation. It isn't simply "free error checking." One should be able to discriminate from problems that require type-checking.
It just seems that in most cases it isn't actually required.
> Spare yourself this yammering rant. They chose Python because that's what everyone else at the company was cool with. End of story.
I don't think it's a bad idea to evaluate the alternatives, even if you are very comfortable with a specific language. Granted we were pretty cool with Python and that is definitely a major factor in the decision, but it can't be the only one.
For example, we were all very comfortable using SVN (another technology Facebook uses and is now locked in with). But we didn't use Subversion; we decided to use Git, because the advantages of using a DVCS outweigh our personal sense of comfort.
I just don't understand why type-checking and speed were factors in choosing the language you were after. If they were, then why even bother looking at Python at all? It isn't a fast language and doesn't have type-checking.
The rest of the article is spent telling me why these features aren't important. Both C# and Java have type-checking (though C# perhaps is a little more loose) and are pretty fast. Yet the article claims that Python is fast enough and that type-checking isn't a requirement because you're more concerned with value assertions (and unit-tests are good enough to validate them).
So essentially the article sets up false premises and knocks them down one by one. Type-checking wasn't actually a requirement. Neither was speed. The only reason we are left with for why Quora chose Python was because that's what most people were familiar with.
I'm not saying it's a bad choice or that your conclusions were incorrect. I just don't think it was a good article.
True, I honestly don't think C# or Java were even in the race. I think the only real alternatives I would've been happy with would've been either Scala or some flavor of ML or Haskell, all of which definitely satisfy the speed and type-checking factors that were mentioned.
Let's put it this way: if any of those languages had half the library support that Python did, then it would've been a decent fight. But as it goes right now it's not even close.
EDIT: Sorry, the library support only applies to ML and Haskell, and I forgot about Scala. I'll have to think about this one; I'm not sure the reasoning for that was entirely well fleshed out.
I guess they're implying that Mono ins't a money maker at Novell? Mono is great and all, but maintaining an entire development platform, along with IDE and and myriad of docs, strictly for internal use may be a bit too much for a company of their size.
My biggest problem with Django is that the entire data model layer is designed with relational database in mind (i.e. normalization and JOINs). Many of the new data stores (RDF stores, Google Data Store for App Engine, etc) are inheritantly non-relational.
We're on Django; there is a relational DB in our architecture, but when you're browsing the site you're nearly always hitting either Solr or a key-value store.
But why wouldn't you use a relational database? It works, the ORM's good, it's fast enough, you're probably not going to hit scaling problems. If you do hit scaling problems, then that's a really really good problem to have.
How have your experiences with web.py been? The disadvantages I saw with it are that it just doesn't have a really large community, plus there are features I just don't want to build myself. Django's built-in admin/ app, for example, or Pylon's error page.
I like starting web apps with web.py, and I like building what may end up being merely demoware or a narrow tech prototype using web.py. I think it excels at whipping up a dynamic Hello World web app in just a few lines of code, with no boilerplate directory tree or scriptage, and no messing around with external servers, and no external code dependencies. Add sqlite when need persistence. Add memcached when need caching. Grow and refactor as you go.
But if I'm very confident it's going to become part of a long-lived dynamic web service with enough of the features Django provides anyway -- especially that awesome built-in admin UI -- then yes I start with Django. The mindshare/community factor is helpful too. I know there are other web frameworks which are decent but going with a big framework other than Django in the Python space today is a bit like going with FreeBSD rather than Linux when all you really need is some sort of free Unix. To pick Linux is to get a bigger ecosystem today and therefore probably also a longer supported future.
Charlie Cheever's comment "Python data structures map well to JavaScript data structures" resonates with me. I'm building something in Erlang right now and having come from Python, it's just plain grating.
No, it was actually my idea of a comedy routine. Around here, attempts at being the forum comedy act are frowned upon and thus end up somewhat similar to masochism, but it's therapeutic in the end.
lately i'm trying to exercise my desire for humor over on Reddit rather than here, for the reasons you stated. Goes down better over there. Plus they have narwhales.
Christ, some people here are fucking uptight. Quality comments are one thing, and HN has done a good job of keeping a quality community, but having a stick up your ass is a different matter.
As far as I can tell there seems to be a lot more peripheral innovation in the ruby camp though, particularly in testing tools. Are there python equivalents to rspec, cucumber, factory_girl/machinist, shoulda, passenger, haml, webrat etc?