Кто там гворил что Ruby рулит?

тогда ассемблер тебе в руки

Хе-хе, тогда возьми в руки это:

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=mlton&l...

P.S. Ходят слухи что он рулит при прямых руках.

Тесты, тесты....

Все эти тесты ничего не стоят, потому что показывают характеристики для какой-то конкретной ситуации. И потом Java, Ruby - это все лишь инструменты, и когда будешь выбирать инструмент - будет пофигу рулит он где-то или не рулит. Главное, что дело свое делает.

если для его нормальной работы с одинаковым кол-вом клиентов потребуется сервер в 15 раз более дороже, чем для java.... то я наверное лучше напишу проект на java, а вырученную денюшку потрачу на более полезные дела ;)

Напейши лучше на mlton'е. А вырученные деньги пропей :)

А чем вообще Ruby лучше того же Python?

>если для его нормальной работы с одинаковым кол-вом клиентов потребуется сервер в 15 раз более дороже, чем для java...

Ну есть у меня большой и дорогой сервер, в 2х стойках (вместе с дисковым массивом). И программы все сплошь на "супербыстром" "C" написаны. А все равно больше 30 клиентов/секунду не обрабатывает.

Не в языке дело.

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=sbcl&la...

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=cmucl&l...

Опенсорсные лиспы наравне с джавой, даже чуть-чуть получше, я так и думал...

правда на таких не больших задачах главное приемущество лиспа мало проявляется

Интересно, что кроме C/Pascal/Fortran (что естественно), очень хороши показатели OCaml и Haskell.

И clean

Кстати интересно почему на самом деле руби такой тормоз, даже по сравнению с Питоном (хотя языки одного класса)

Тебя колышет производительность скриптового языка?!? :-O

Ты лечиться пробовал? От навязчивых идей, и т.п....

А тебя нет? При прочих равных это тоже довод, в пользу того же Пайтона...

А они сами это признают. AFAIR это один из ближайших project goal'ов -- ускорение. Хотя по моему опыту, быстродействие языка как такового смазывается скоростью работы базы данных и объемом памяти.

Так ведь нет их, прочих равных...

Если у тебя bottleneck гарантированно не в скрипте, то разница в производительности в пару сотен раз тебя ну ни разу не должна интересовать.

... а если bottleneck как раз в скрипте, его надо переписывать на компилируемом языке?

Да. Только не скрипт, а сам bottleneck. И то, только после того, как убедишься, что простой алгоритмической оптимизацией bottleneck не устранишь.