11 ms·

Not sure if they will gain a lot of performance from this transition...according to shootout ( http://shootout.alioth.debian.org/u64q/which-programming-language

Not sure if they will gain a lot of performance from this transition...according to shootout ( http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64q/which-programming-lan... ) python is only few % faster than ruby. Maybe they should consider porting their entire ecosystem to JVM as twitter did it.

lastkarrde 15y ago
They could run the site on PyPy as opposed to the CPython interpreter. Postgres and Django are well supported. https://bitbucket.org/alex_gaynor/pypy-postgresql https://bitbucket.org/alex_gaynor/pypy-postgresql http://speed.pypy.org/timeline/#/?exe=3,6,1,5&base=2+472&ben=django&env=1&revs=200&equid=off http://speed.pypy.org/timeline/#/?exe=3,6,1,5&base=2+472...
- timc3 15y ago
  I would feel hard pressed to sell PostGres with PyPy as well supported at the moment. Django maybe, purely because it doesn't depend on too many C Libs.
timc3 15y ago
They could gain in productivity and ease of support
- latch 15y ago
  You're implying that python is more productive than ruby? I've never heard that claim before.
  - andybak 15y ago
    Really? I've heard both that claim and it's c.ounterclaim several times and come to the conclusion that it's an interesting yet ultimately futile discussion.
  - danneu 15y ago
    Not at all. You can be more productive in another language for reasons that have nothing to do with the merits of either language. For instance, the Justin.tv guys already use a lot of Python in their stack outside the RoR app server.
  - timc3 15y ago
    I am not implying that one language is more productive than another, just that it might be more productive for that team with their codebase.
riffraff 15y ago
performance of a web app is quite likely more dependent on factors other than the raw interpreter speed, e.g. straight rack apps could easily be five times faster than rails apps using the same interpreter.
rsynnott 15y ago
The thing about the programming language shootout is that the benchmarks are optimized to within an inch of their life, and in particular don't generate much garbage. This may have changed, but last time I checked (MRI) Ruby's garbage collector was _stunningly_ slow.

lastkarrde 15y ago

They could run the site on PyPy as opposed to the CPython interpreter. Postgres and Django are well supported. https://bitbucket.org/alex_gaynor/pypy-postgresql https://bitbucket.org/alex_gaynor/pypy-postgresql http://speed.pypy.org/timeline/#/?exe=3,6,1,5&base=2+472&ben=django&env=1&revs=200&equid=off http://speed.pypy.org/timeline/#/?exe=3,6,1,5&base=2+472...

timc3 15y ago
I would feel hard pressed to sell PostGres with PyPy as well supported at the moment. Django maybe, purely because it doesn't depend on too many C Libs.

timc3 15y ago

They could gain in productivity and ease of support

latch 15y ago
You're implying that python is more productive than ruby? I've never heard that claim before.
- andybak 15y ago
  Really? I've heard both that claim and it's c.ounterclaim several times and come to the conclusion that it's an interesting yet ultimately futile discussion.
- danneu 15y ago
  Not at all. You can be more productive in another language for reasons that have nothing to do with the merits of either language. For instance, the Justin.tv guys already use a lot of Python in their stack outside the RoR app server.
- timc3 15y ago
  I am not implying that one language is more productive than another, just that it might be more productive for that team with their codebase.

riffraff 15y ago

performance of a web app is quite likely more dependent on factors other than the raw interpreter speed, e.g. straight rack apps could easily be five times faster than rails apps using the same interpreter.

rsynnott 15y ago

The thing about the programming language shootout is that the benchmarks are optimized to within an inch of their life, and in particular don't generate much garbage. This may have changed, but last time I checked (MRI) Ruby's garbage collector was _stunningly_ slow.