Ruby или Python...Что выбрать?

С клиентской стороны: JavaScript+HTML. С сервера: CGI.

Остальное от лукавого.

Если на shared hosting, где будет > 1-3 проектов, то лучше python. Просто Ruby на FastCGI, SCGI(1-3 секунды на запрос) и тем более на CGI ужасно тормозит. На Mongrel летает, но один процесс Mongrel ждёт 50 мегов, поэтому больше одного проекта на хостинге за 10$ ты не запустишь с нормальной скоростью. Может, с выходом ruby-2 дела будут намного лучше.

А так лучше ruby, если нужен тру ООП, и есть заказчик, который заплатит за хост :-)

Но в любом случае, интересней учить Ruby и его возможности постичь в действии на Ruby on Rails.

как ужастно все с руби!

тогда уж порекомендую изучить aspnet2/mono.

>Просто Ruby на FastCGI, SCGI(1-3 секунды на запрос) и тем более на CGI ужасно тормозит. На Mongrel летает, но один процесс Mongrel ждёт 50 мегов

неправда) CGI - да, лучше даже не пробовать. А на fcgi очень можно жить. Про монгрел и 50 метров тоже не всегда верно. У меня жрут в среднем от 15 до 30.

2nicebytes - VB ждет тебя, юный партизан полной луны.

Если ты задаешь этот вопрос, значит стоит посмотреть Руби. Больше возможностей и язык поинтереснее(особенно после ПХП).

Если ты задаешь этот вопрос, значит стоит посмотреть Питон.

8)

> VB ждет тебя, юный партизан полной луны.

ха, ромка, не смеши меня :)

было дело, с VB и VBA приходилось много програмить лет 8-10 назад.
но мне синтаксис VB очень не по душе.

не знаю как тебе fcgi помогает. imho, лучше вначале узнать как cgi работает, дальше все равно. чем меньше абстракций между кодом и тем что делает процессор, тем лучше :)

> Просто Ruby на FastCGI, SCGI(1-3 секунды на запрос)

У меня явно какой-то неправильный руби. :) Или я просто вырубил development mode в рельсах, может дело в этом? :)

Не знаю. Возможно, дело в системных ресурсах. production включен

Я замерял через time и wget. Сервер с руби удалённый. Статическая страница загружалась за 0.3 секунды, а страница с дефолтной установкой radiant - 1-3 сек. Сегодня уже около 1.2. Стоит SCGI. Уже больше похоже на правду?

Что такое SCGI я не знаю (а в гугль лень), сам пользовал только mongrel и fastcgi, но у меня даже webrick в development mode по секунде (1.2 максимум) странички генерил (несложная такая страничка, что-то типа форума). А ты говоришь 1-3 секунды. Явно что-то в консерватории не то, точно тебе говорю. Ищи причину.

Почитал про SCGI. :) Насколько я понял, ничем оно не лучше и не хуже, чем FastCGI, только проще в реализации. В общем результаты твои явно слишком большие и требуют оптимизации.

>было дело, с VB и VBA приходилось много програмить лет 8-10 назад.

может, стоит подумать о триумфальном возвращении?

>imho, лучше вначале узнать как cgi работает, дальше все равно.

имелось в виду - не пробовать использовать ruby с обычным CGI. Ибо тормоз страшный.

>чем меньше абстракций между кодом и тем что делает процессор, тем лучше :)

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

2romka:

>>чем меньше абстракций между кодом и тем что делает процессор, тем лучше :)

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

если делаешь небольшие типовые проекты, то да, скорость и удобство прокатит.

но чуть посложнее проект - все, тебе конец.

Никакого конца, спокойно читаем логи и вообще занимаемся профилированием. А зачастую можно вообще увеличить быстродействие на порядок чисто админскими мерами, не меняя ни строчки кода.

Спокойствие и чтение логов никто не отменял.

Если заниматься сопровождением своих сайтов то больше одного-двух не получится.

imho, сайт должен обходиться минимумом администрирования. минимум утечек памяти, минимум перезагрузок и обновлений.

>Если ты задаешь этот вопрос, значит стоит посмотреть Питон.

Если ты задаешь этот вопрос, значит ты созрел для http://java.sun.com/learning/tutorial/index.html http://java.sun.com/developer/codesamples/basics.html

Нормальные разработчики уже поняли <I looked at it seriously several times and always found it to seem clunky, hard to read and harder to write.> http://www.javalobby.org/java/forums/t92777.html и я с ними согласен, что шум вокруг Ruby раздут искусственно, дабы погреть ручки на продаже серии книжек.

Если уж охота глумиться как Луговский в функциональном стиле, лучше взять SISC sisc-scheme.org или Groovy

Могу книжку кинуть Groovy Programming An Introduction for Java Developers

Только сейчас хостер сделал для меня mongrel. Теперь летает с 0.3 сек, как статик контент :)

>но у меня даже webrick в development mode по секунде (1.2 максимум)

webrick даже лучше, чем cgi хотя бы тем, что каждый раз не надо запускать всю подноготную рельсов, бездумно тратя ресурсы. Правда, webrick может обслуживать только одного клиента за раз :)

Дык cgi-то понятно, что ни один нормальный человек с рельсами не пользует. Тут даже и сравнивать ничего не надо.

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

Пардон. Имелся в виду шустрый CGI.

> Только сейчас хостер сделал для меня mongrel. Теперь летает с 0.3 сек, как статик контент :)

сравните быстродействие с aspnet 2.

фрагмент лога CassiniEx сервера написанного на Net (аналог в mono - XSP), последняя страничка - миллисекунды. Каждый запрос prod.aspx обращается к XML  базе и динамически формирует контент страницы:


2006-10-13 12:51:47 127.0.0.1 GET /Aps/pic/mvv-01.jpg - 80 127.0.0.1 200 4186 467 0
2006-10-13 12:52:36 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 31933 13103 78
2006-10-13 12:52:36 127.0.0.1 GET /Aps/pic/mvv-02.jpg - 80 127.0.0.1 200 3937 467 16
2006-10-13 12:52:37 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 31938 13475 78
2006-10-13 12:52:38 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 31938 13477 94
2006-10-13 12:52:39 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 31938 13477 94
2006-10-13 12:52:39 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 31938 13477 109
2006-10-13 12:52:40 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 31938 13477 94
2006-10-13 12:52:41 127.0.0.1 POST /Aps/prod.aspx sid=4 80 127.0.0.1 200 32512 13478 109
2006-10-13 12:52:43 127.0.0.1 GET /Aps/prod.aspx sid=110 80 127.0.0.1 200 29952 631 62
2006-10-13 12:52:45 127.0.0.1 POST /Aps/prod.aspx sid=110 80 127.0.0.1 200 31925 12365 78
2006-10-13 12:52:45 127.0.0.1 GET /Aps/pic/Mva-08.jpg - 80 127.0.0.1 200 10082 469 0
2006-10-13 12:52:47 127.0.0.1 POST /Aps/prod.aspx sid=110 80 127.0.0.1 200 31924 13466 78
2006-10-13 12:52:47 127.0.0.1 POST /Aps/prod.aspx sid=110 80 127.0.0.1 200 31924 13511 94
2006-10-13 12:52:48 127.0.0.1 GET /Aps/prod.aspx sid=111 80 127.0.0.1 200 29669 633 94

Ты FastCGI вообще когда-нибудь пользовался? Там вообще-то тоже процессы в памяти висят, а не запускаются на каждый запрос.

s/страничка/число в строке/

>Ты FastCGI вообще когда-нибудь пользовался? Там вообще-то тоже процессы в памяти висят, а не запускаются на каждый запрос.

Выяснилось, что на сервере был просто CGI. SCGI у них только на нескольких старых серверах :( Теперь понятно, почему такая тормозилла. Извиняюсь за дезинформацию.

Это ты на localhost замерял? А я замерял на удалённом сервере.

Не хочу показаться грубым, но засунь свой asp себе в задницу. Пока MS не прекратит ломать API и .NET не станет полностью кроссплатформенным, то нечего и пользоваться пока этим windows-only дерьмом.

для выяснения быстродействия серверного решения надо смотреть именно local, иначе ты увидишь только задержки на хопах от тебя до сервера и обратно.

aspnet уже реализован в mono, для linux. сейчас есть aspnet2.

imho, разработчик должен знать истинное положение дел, а в задницу кому-то лучше засунуть свои дешевые понты.