Another "why" that was left out in the article, something that is of great concern to a lot of projects, is computational performance. A whole lot of good can be said about both Python and Ruby, but "swift performer" is definitely not one of those things.
That kind of performance just doesn't matter that much though. I recently benchmarked my fairly standard Rails app on 1.8.7 vs. 1.9.2, and the numbers for delivering a page are basically the same.
1.9.2 is much faster for calculating Fibonacci numbers, sure, but since webapps are mostly IO bound it just doesn't matter.
Oh - I fully agree. For most situations, raw computation is irrelevant. But even in the cases where it matters, PHP isn't remarkably faster than its closest alternatives.
Let's be honest. When people "use Ruby", it's very unlikely that they are using JRuby or Ruby 1.9. Similarly, when people "use Python", they are using 2.7 or lower, not 3.1.
The reason is because the older versions of each are the ones with the libraries.
But interestingly, this is not the case with Perl, as new releases have 99% backcompat with old releases. Even old code that uses a new piece of syntax (like "say" from 5.10) in the old way continues to work!
I don't have any hard numbers, but there's been a massive uptake in 1.9 since the release of 1.9.2. I've been doing all of my projects in 1.9 for a while now, and I very rarely run into compatibility errors.
I'm pretty involved in the ruby community, and I've generally seen an increase in people talking about using it. Also with the Rails 3 release, lots of people were waiting to do one big massive upgrade of both Ruby and Rails at the same time. It's been long enough now that lots of people have moved their projects over.
Like I said, I have no numbers, so fundamentally it is just a guess.
If you say that you're using Ruby 1.9 then not wanting to be quarrelsome that's good enough for me to accept that you are using Ruby 1.9.
And I'll grant that you're part of the community on your say so.
But being "part of the community" doesn't magically enfuse you with knowledge about what proportion of the community is using what version of Ruby. To be educated about that is to count the numbers.
You might as well have linked to NCAA Basketball scores!
Let's be honest. When people "use Ruby" (or Python) you really don't know what proportion of them are using which version. And the data you have a lot of does not help with that.
Nor does the data you have a lot of tell us what proportion of Perl users use which version of Perl.
I have to agree. Bolting a full stack framework on top of PHP just doesn't appeal much to me. If you want that kind of organisation in your application, I would much prefer something other than PHP. PHP excels at keeping complexity down. If you don't work within that paradigm, then Python or Ruby are probably better alternatives.
From the outside looking in the vast majority of people I know making web apps in ruby are doing so with rails. For better or for worse there is that full blow framework culture there that hasn't been replicated in PHP either due to fragmentation or the amount of functions built directly in the language.
True. I wouldn't say that it's because of the number of things built into the language though, it's more that Rubyists tend to care about software engineering, and so they'd rather do something the right way with full tooling than just throw up one page spaghetti scripts.
