Hacker News Reader

Comment by hackermom | Hacker News Reader

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.

View on HN

Python is generally a bit faster than PHP though, and while Ruby is dog slow, both languages are in the heavy end for their class.

Ref: http://shootout.alioth.debian.org/u32/which-programming-lang...

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.

Who's shown Fib?

If "it just doesn't matter" then what's the point of 1.9.2 performance improvement?

There's not much of a point -- that's why 1.8.7 is still around, and why uptake on 1.9.2 has been so slow.

If 1.9.2 really made every HTTP request go 2x as fast, don't you think every Ruby shop would have switched to 1.9.2 at least a year ago?

Strangely you show Ruby 1.8.7 but not Ruby 1.9 or JRuby ;-)

http://shootout.alioth.debian.org/u32/which-programming-lang...

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!

Let's be honest. When people "use Ruby" (or Python) you really don't know what proportion of them are using which version.

The reason is you have no data.

But interestingly, this is also the case with Perl - you have no data.

I have a lot of data: http://stats.cpantesters.org/pmatrix-month.html

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 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.

How do you know there's been a massive uptake when you don't have any numbers? Aren't you just guessing?

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.

That's correct it's just a guess.

And of course this is just a guess too - "It's been long enough now that lots of people have moved their projects over."

Maybe we could step from wag to anecdote if there has been a straw poll at some recent Ruby conference asking which version the attendees were using?

It's a guess, but if you're part of the community (and I am) it's at least an educated guess :) I'm developing in Ruby 1.9 as well.

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.

careful though, if you take into account equivalent abstractions (rails vs symfony vs django) this argument may toggle against php.

PHP isn't to hard to do away with the abstraction though, or just go with some lightweight helper libraries.

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.

Just so you know: Ruby and Python also have 'no framework' ways of making apps, just like PHP does.

The culture has just decided that at least using a little bit (even if it's only 1500 lines) of framework is worth it.

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.

Reply on news.ycombinator.com