Довольно известный Ruby-ист Mauricio Fernández (в последнее переключившийся на OCaml) опубликовал свое сравнение скорости работы простых web-приложений, написанных на Ruby+RubyOnRails, OCaml/Ocsigen и lighttpd+FastCGI+C: Standalone web applications using OCaml + Ocsigen, benchmarked against Rails.

Имхо, комментарии к этому сравнению местам даже интереснее.

Как я понимаю, Ocsigen не доступен под Windows, для меня, например, это show stopper..
И, кажется, в нем ничего нет про работу с БД, в то время как в RoR active records — одна из главных фишек.

E>Довольно известный Ruby-ист Mauricio Fernández (в последнее переключившийся на OCaml) опубликовал свое сравнение E>скорости работы простых web-приложений

Вообще, результаты абсолютно предсказуемые, но все равно прикольно. На том же железе Mochiweb/Yaws должны показывать
где-то в районе 2500 — 2800 RPS, python (по крайней мере phenopy без кэширования) — 450 — 600. Радует маленький
memory footprint окамла.

Померял бы кто нибудь java/tomcat до кучи. Или на нем уже никто ничего не пишет?

DM>Как я понимаю, Ocsigen не доступен под Windows, для меня, например, это show stopper..

Неужели не соберется? Со сборкой окамловых приложений под винду есть проблемы?

DM>И, кажется, в нем ничего нет про работу с БД, в то время как в RoR active records — одна из главных фишек.

dmz@x200:~$ apt-cache search ocaml database
cameleon - integrated development environment for OCaml
libmysql-ocaml - OCaml bindings for MySql
libmysql-ocaml-dev - OCaml bindings for MySql
libocamlodbc-ocaml-dev - UnixODBC database bindings for OCaml
libpostgresql-ocaml - OCaml bindings to PostgreSQL's libpq
libpostgresql-ocaml-dev - OCaml bindings to PostgreSQL's libpq
libsqlite3-ocaml - Embeddable SQL Database for OCaml Programs
libsqlite3-ocaml-dev - Embeddable SQL Database for OCaml Programs

С одной стороны — это не ORM. С другой стороны — нам вот пришлось послать все питоновские ORM-ы в топку, и
написать свой меппер. С третьей стороны — быть может, в ФЯ никакой ORM и не нужен. По крайней мере,
при использовании мнезии, как-то от его отсутствия не страдаешь.

Здравствуйте, dmz, Вы писали:

[cut]

dmz>С одной стороны — это не ORM. С другой стороны — нам вот пришлось послать все питоновские ORM-ы в топку, и
dmz>написать свой меппер. С третьей стороны — быть может, в ФЯ никакой ORM и не нужен. По крайней мере,
dmz>при использовании мнезии, как-то от его отсутствия не страдаешь.

Если речь про эрланговскую мнезию, то оно не совсем чтоб РСУБД, плюс интересно как из окамла туда "ходить"?

К>Если речь про эрланговскую мнезию, то оно не совсем чтоб РСУБД, плюс интересно как из окамла туда "ходить"?

Ну да, оно не очень реляционное. Но все равно — маппером особым никаким не пользуемся — такой подход вполне подойдет для связки Ocaml — РСУБД.

Думаю, ходить окамлом в мнезию не надо, т.к. в мнезии самый жир, что она находится в адресном пространстве клиента, а так же эрланг с ней
хорошо интегрируется. Хотя пишут же какие-то извращенцы компилятор Haskell в эрланговой машины. При желании, наверное, можно и для окамла
такое написать, хотя окамл будет уже не совсем тот.

Здравствуйте, dmz, Вы писали:
dmz>С одной стороны — это не ORM. С другой стороны — нам вот пришлось послать все питоновские ORM-ы в топку, и
dmz>написать свой меппер. С третьей стороны — быть может, в ФЯ никакой ORM и не нужен. По крайней мере,
dmz>при использовании мнезии, как-то от его отсутствия не страдаешь.

не думаю, что эта буква O имеет отношение к ООП. ORM по-другому называется просто persistance

BZ>не думаю, что эта буква O имеет отношение к ООП. ORM по-другому называется просто persistance

Ну, скажем, в ФЯ вполне комфортно себя можно чувствовать, работая прямо с туплами или рекордами, каковые и будет
отдавать API. При этом не будет ощущения, что что-то делаешь не так.

В ООП же как. Возвращают тебе RecordSet. RecordSet — объект не кошерный, к тому-же, может содержать некий стейт — курсор там, например.
Если что-то внешнее случилось — то получить очередной объект сета может быть невозможно. Поэтому перегоняешь его в модель.

Модель тоже штука не простая — если вдруг есть какие-то зависимости, то может вылезти и ленивая загрузка коллекций (ага, где-то там
неявно будет что-то, что умеет лазить в базу). Соответственно, если мы захотим пропихнуть это через маршалинг — то, вероятно, придется
это дело запихать в третью иерархию объектов. Движуха, в общем!

А тут — возвращают тебе список туплов, и все — end of story. Он же в соседнюю ноду, он же в JSON. Необъектно, хоть ты тресни

Здравствуйте, dmz, Вы писали:

dmz>Ну да, оно не очень реляционное. Но все равно — маппером особым никаким не пользуемся — такой подход вполне подойдет для связки Ocaml — РСУБД.

JFYI: тот же Фернандез проводил эксперименты по созданию для OCaml EDSL для работы с РСУБД: [OCaml] Addressing the ORM problem, typed relational algebra

Автор: eao197
Дата: 01.11.07

. Может он результатами этих экспериментов до сих пор пользуется.

dmz>С одной стороны — это не ORM. С другой стороны — нам вот пришлось послать все питоновские ORM-ы в топку, и
dmz>написать свой меппер. С третьей стороны — быть может, в ФЯ никакой ORM и не нужен. По крайней мере,
dmz>при использовании мнезии, как-то от его отсутствия не страдаешь.

Очень интересно выглядит Олеговский Takusen, для хаскеля. Там, как я понял, вместо возвращения потока записей, принимается на вход функция, этот поток сворачивающая, и где-то внутри API применяется.

Здравствуйте, dmz, Вы писали:

DM>>Как я понимаю, Ocsigen не доступен под Windows, для меня, например, это show stopper..

dmz>Неужели не соберется? Со сборкой окамловых приложений под винду есть проблемы?

Если не под Cygwin, то проблем куча: нет fork'a, нет select'a для несокетов, не реализована часть стандартной библиотеки (в том числе Unix.establish_server), да и собирать не чем — не работают стандартные вещи типа ocamlbuild, ocamlfind, GODI.

Меня всегда удивляли люди, называющие кроссплатформенными решения, использующие fork и bash.

DM>>И, кажется, в нем ничего нет про работу с БД, в то время как в RoR active records — одна из главных фишек.

dmz>dmz@x200:~$ apt-cache search ocaml database

Отдельные библиотеки для работы с отдельными базами есть, но они не интегрированы в фреймворк. Имхо, именно ActiveRecord — сердце рельсов, делающее разработку на рельсах столь удобной и приятной. Если убрать из рельсов ActiveRecord, что останется? Сторонний невыдающийся веб-сервер, сторонний банальный джижок шаблонов и свое отображение путей на методы — не густо.

Здравствуйте, eao197, Вы писали:

E>Довольно известный Ruby-ист Mauricio Fernández (в последнее переключившийся на OCaml) опубликовал свое сравнение скорости работы простых web-приложений, написанных на Ruby+RubyOnRails, OCaml/Ocsigen и lighttpd+FastCGI+C: Standalone web applications using OCaml + Ocsigen, benchmarked against Rails.

E>Имхо, комментарии к этому сравнению местам даже интереснее.

Посмотрел в исходники Ocsigen и вижу DynLoad я правильно понимаю что байт код Ocaml'а настолько шустрее руби?

Здравствуйте, D. Mon, Вы писали:

DM>Если не под Cygwin, то проблем куча: нет fork'a, нет select'a для несокетов, не реализована часть стандартной библиотеки (в том числе Unix.establish_server), да и собирать не чем — не работают стандартные вещи типа ocamlbuild, ocamlfind, GODI.

http://www.virtualbox.org/

DM>Отдельные библиотеки для работы с отдельными базами есть, но они не интегрированы в фреймворк. Имхо, именно ActiveRecord — сердце рельсов, делающее разработку на рельсах столь удобной и приятной. Если убрать из рельсов ActiveRecord, что останется?

ActiveRecord — это всего-лишь динамический ORM. Его эффективность под большим вопросом, равно как и способность маппить
нетривиальные вещи. Кроме того, он навязывает определенные стереотипы дизайна базы, которые могут не всегда быть
подходящими. В любом случае, если мы говорим о масштабируемости приложения, то слой доступа к данным, использует он ORM
или нет — обязан быть изолирован, и таскать ORM-зависимые вещи по всем слоям — нельзя.

Я все это веду к тому, что отсутствие ORM (и уж тем более динамического) не такая большая потеря; в любом случае, ad-hoc
замена пишется за считанные дни, к тому же, это разовая инвестиция при переходе на новую технологию.

DM>Сторонний невыдающийся веб-сервер, сторонний банальный джижок шаблонов и свое отображение путей на методы — не густо.
Да. Добавим сюда самый тормозной из известных интерпретатор, жадный до памяти, и стремный ORM — и получим законченную картину.

Здравствуйте, FR, Вы писали:

FR>Посмотрел в исходники Ocsigen и вижу DynLoad я правильно понимаю что байт код Ocaml'а настолько шустрее руби?

Интерпритатор, который был бы медленее Ruby, нужно еще поискать. Так что, думаю, даже в режиме байт-кода OCaml уделает Ruby. А уж если его собрать в stand-alone native приложение... (Фернандез, насколько я понял, гонял именно нативный код, а возможность Ocsigen создавать stand-alone приложения реализована в пока не выпущенной, development-версии Ocsigen, если я ничего не перепутал).

Здравствуйте, FR, Вы писали:

FR>Посмотрел в исходники Ocsigen и вижу DynLoad я правильно понимаю что байт код Ocaml'а настолько шустрее руби?

Так DynLoad и в нативном коде теперь работает.

Здравствуйте, D. Mon, Вы писали:
DM>И, кажется, в нем ничего нет про работу с БД, в то время как в RoR active records — одна из главных фишек.

Там вроде есть решение для перзистенса — ocsipersist. Не ORM, конечно, но и не то, чтоб ничего нет.

Здравствуйте, FR, Вы писали:

FR>я правильно понимаю что байт код Ocaml'а настолько шустрее руби?

Ocaml'овский байткод раз в 5 медленнее нативного, т.е. раза в 4 быстрее байткодов Питона, Перла и др., которые раза в 2-3 быстрее Руби.

Здравствуйте, dmz, Вы писали:

dmz>ActiveRecord — это всего-лишь динамический ORM. Его эффективность под большим вопросом

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

dmz>Да. Добавим сюда самый тормозной из известных интерпретатор,

Есть тормознее — Ребол.

Здравствуйте, D. Mon, Вы писали:

DM>Есть тормознее — Ребол.

Да ребол это вещь, такую же концентрированную мощь до него я только в форте видел