Нет, не надо таких советов, эти лекарства в Омереке без рецепта не продают, а за рецептом идти дорого, у меня страховки нет. Так что придется читать книжку и делать вид что так и надо.
Ну это мы еще посмотрим. Нам пока питона с континуациями (русское слово-то есть для этого?) хватает выше крыши :-)
For starters, хочется понять насколько на эрланге можно писать веб. А для этого надо понять что в эрланге работает вместо HTML::Template, грубо говоря.
тогда надо смотреть на yaws в качестве веб-сервера (с шаблонами). или на mochiweb (как говорят, но я не смотрел на него) можно еще earlyweb - примерный аналог RoR, и было еще что-то - народ сейчас масово кинулся писать такие вещи :-) P.S. по поводу continuations - я что-то не помню адекватного русского термина
Армстронговская книжка про ерланг хороша для начала, но я вот жду выхода в начале 2009-го книжек про OTP (Concurrent Programming with Erlang/OTP от Manning), и кто-то еще собирался выпустить книжку про advanced programming with Erlang
Так себе на нем писать веб. Проблемы с шаблонизаторами, даже с XSLT там плохо - один кривой биндинг саблотрона. Конечно, можно написать любой биндинг самостоятельно - но, в общем, будучи написанным не на эрланге - оно будет плохо масштабироваться по процессам, а будучи написанном на эрланге - оно будет тормозить. Плюс слабовата работа со строками, плюс тормозные те-же регекспы.
Кстати, никакого волшебства в плане прозрачной кластеризации по нодам в случае веба эрланг не даст - т.е. придется это делать самостоятельно, и в общем случае это будет мало отличаться от решения на любой другой платформе - reverse proxy + пачка fcgi процессов.
Смех смехом, но тут бы я посмотрел на хаскелл - там есть все, чего нет в эрланге (легкие потоки тоже есть), а нет только серверной инфраструктуры и мнезии.
Ищо там нету concurrent GC, нативного RPC и софт реалтайм. Особенно последнее -- если вы не знаток кишок ghc, поиск проблем с производительностью (которые возникают, благодаря ленивости, в самых неожиданных местах) начинается с долгих танцев с бубном вокруг компилятора, а заканчивается обычно превращением исходников в дикобраза, утыканного вызовами `seq` и $!
Стеклесс питон не масштабирует по процессорам/ядрам. Т.е это просто газирование лужи. Плюс, поскольку в питоне дофига всего в нативных библиотеках - они запросто будут блокироваться.
У нас на самом деле какая засада - нам нужен веб-спайдер, который может подолгу залипать на внешних сайтах (сессии и серии POST-запросов) - ну понятно, почему. Текущий написан на питоне; в питоне нельзя убить зависший тред - и таймаут можно повесить только на сокеты и глобально; у нас поэтому сделано совершенно ракообразное решение из пула процессов, каждый из кототорых держит количество тредов. Собираемся от этого гимора избавляться - как раз рассматривал стеклесс питон и эрланг; первый в топку, второй - очень бедные и недоделанные библиотеки во всем, что не касается телекома. Так что победил, видимо, хаскелл как раз - леговесный относительно питона, удобные потоки и огромная куча (как для перла практически) библиотек и вообще выглядит очень живо.
Ну, до перла там еще далеко -- вот буквально последний раз хотел размяться, для чего-то мелкого хаскель заюзать вместо питона -- оказалось что даже приемлемо шуструю считалку md5 не так то просто найти.
Но в эрланге с библиотеками реально хуже, да. Причем даже то что есть, оно нередко написано вполне качественно, но документации при этом нету или почти нету (например, xmerl).
Eve Online это скорее не в плюс stackless python. более тормозной и глючной игры еще видел. Бой на 1000 человек это гарантированный лаг с невозможностью управления или черный экран минут на 40.
Кстати вот софт реалтайм, это все-таки очень приятная фича эрланга.
В том плане, что там есть смысл говорить о производительности в терминах микросекунд, реально можно что-то там измерять и сравнивать, на уровне функций -- а этого мне например, как человеку с C/C++ бэкграундом, в том же петоне сильно не хватает иногда.
Я помню, когда в официальной питоновской рассылке какой-то товарищ спрашивал, как быстро работает вставка в массив в терминах O(N), ответ был "бугага, чувак, ты о чем вообще, забудь такие слова, это ж питон".
Мне XML не нужен, слава богу, мне бы по простому какой-нибудь вменяемый шаблонный процессор, чтоб отделить код от представления. HTML::Template хватило бы вполне. Минус конечно в том, что если на HTML::Template найти верстальщика еще как-то можно, то на всякий изврат с эрлангом - фиг. А использовать для этого девелопера - дорого.
По поводу XML кстати зря. Так как найти верстальщика на XSLT будет попроще, чем на всякие другие извраты - вещь, может и сложная на вид, но хотя бы широко распространенная и стандартная, в отличие от зоопарка прочих шаблонизаторов.
А еще здорово экономит время, т.к. в нем есть наследование шаблонов, перегрузка элементов; можно делать библиотеки элементов и т.п. - в общем, большинство самодельных шаблонизаторов резко сливают по возможностям.
Также, оно может работать и на клиенте - это дает возможности 1) разгрузить сервер 2) использовать для AJAX те-же шаблоны и того-же верстальщика, что и для server-side.
Я боюсь что с работой на клиенте там все тоже самое как "и все у них так". То есть есть три броузера, и в них все радикально разным образом работает :-)
Они выстречаются; тот же яндекс регулярно себе их находит в количествах; да и мы себе нашли одного.
Что касается радикально разного образа работы - то нет, все работает лучше, чем можно было бы ожидать; ну и самое главное - оно работает не хуже чем альтернатива на JSON+JS, но гораздо легче в поддержке.
Еще точнее так - если смочь утрамбовать задачу в рамки мнезии - то приход от использования эрланга на вебе будет. А если не смочь - то врядли. При том, что в поддержке мнезия достаточно неприятная штука по сравнению с SQL базами. Зато распределенная дальше некуда.
При том, что в поддержке мнезия достаточно неприятная штука по сравнению с SQL базами. Можно кровавых подробностей? Чем мнезия неприятна? (disclaimer: я только интересующийся эрлангом, знаю пока мало, но книжки изучаю.)
Не то, что бы они будут кровавые - но на моей памяти - внесение изменений в схему данных - гораздо более геморойное дело, чем для обычной связки sql/код приложения; вообще напряжно администрировать базу по сравнению с sql-ными - бедный тулкит, обычными sql-скриптиками не отделаешься; на DBA это дело не скинешь, так как не существует в моей объективной реальности mnesia-DBA, все на разработчиках; встречаются глюки с репликацией и т.п.
Короче, это тяжело описывать - это можно только посмотреть - в эрланге вообще и мнезии в частности все другое. Жить с этим можно - но где взять например админов для мнезийных баз - я вообще не представляю. Или будете обучать сами с нуля, или этим будут заниматься разработчики.
почитал что нашёл, ничего не понял. эта мнезия distributed queries умеет? если да, откуда она знает, на каких нодах искать? secondary indexes есть? distributed transactions есть?
Лучший шаблонизатор по-моему это ErlyDTL (http://code.google.com/p/erlydtl/) -- реализация языка шаблонов из django на эрланге. Он довольно выдержан, такскть, идеологически, в отличие от пестрого erlyweb.
Но веб-морду на ерланге писать это все-таки, по моим впечатлениям, не фонтан -- синтаксис мешает, особенно то что хэшей (т.е. hash_map) нету. Вот сам бэкенд, с интерфейсом на каком-нибудь JSON-RPC -- действительно приятно и легко.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
For starters, хочется понять насколько на эрланге можно писать веб. А для этого надо понять что в эрланге работает вместо HTML::Template, грубо говоря.
no subject
можно еще earlyweb - примерный аналог RoR, и было еще что-то - народ сейчас масово кинулся писать такие вещи :-)
P.S. по поводу continuations - я что-то не помню адекватного русского термина
no subject
велосипедакнижки не было.no subject
no subject
Кстати, никакого волшебства в плане прозрачной кластеризации по нодам в случае веба эрланг не даст - т.е. придется это делать самостоятельно, и в общем случае это будет мало отличаться от решения на любой другой платформе - reverse proxy + пачка fcgi процессов.
Смех смехом, но тут бы я посмотрел на хаскелл - там есть все, чего нет в эрланге (легкие потоки тоже есть), а нет только серверной инфраструктуры и мнезии.
no subject
no subject
no subject
Но, кстати, для бэкенда и легких потоков есть еще stackless python -- я сам не пробовал, но, говорят, вроде ничего. MMORPG Eve Online на нем написана.
no subject
У нас на самом деле какая засада - нам нужен веб-спайдер, который может подолгу залипать на внешних сайтах (сессии и серии POST-запросов) - ну понятно, почему. Текущий написан на питоне; в питоне нельзя убить зависший тред - и таймаут можно повесить только на сокеты и глобально; у нас поэтому сделано совершенно ракообразное решение из пула процессов, каждый из кототорых держит количество тредов. Собираемся от этого гимора избавляться - как раз рассматривал стеклесс питон и эрланг; первый в топку, второй - очень бедные и недоделанные библиотеки во всем, что не касается телекома. Так что победил, видимо, хаскелл как раз - леговесный относительно питона, удобные потоки и огромная куча (как для перла практически) библиотек и вообще выглядит очень живо.
no subject
Но в эрланге с библиотеками реально хуже, да. Причем даже то что есть, оно нередко написано вполне качественно, но документации при этом нету или почти нету (например, xmerl).
no subject
no subject
В том плане, что там есть смысл говорить о производительности в терминах микросекунд, реально можно что-то там измерять и сравнивать, на уровне функций -- а этого мне например, как человеку с C/C++ бэкграундом, в том же петоне сильно не хватает иногда.
Я помню, когда в официальной питоновской рассылке какой-то товарищ спрашивал, как быстро работает вставка в массив в терминах O(N), ответ был "бугага, чувак, ты о чем вообще, забудь такие слова, это ж питон".
no subject
no subject
no subject
Минус конечно в том, что если на HTML::Template найти верстальщика еще как-то можно, то на всякий изврат с эрлангом - фиг. А использовать для этого девелопера - дорого.
no subject
А еще здорово экономит время, т.к. в нем есть наследование шаблонов, перегрузка элементов; можно делать библиотеки элементов и т.п. - в общем, большинство самодельных шаблонизаторов резко сливают по возможностям.
Также, оно может работать и на клиенте - это дает возможности 1) разгрузить сервер 2) использовать для AJAX те-же шаблоны и того-же верстальщика, что и для server-side.
no subject
А верстальщиков с XSLT я как-то не встречал.
no subject
Что касается радикально разного образа работы - то нет, все работает лучше, чем можно было бы ожидать; ну и самое главное - оно работает не хуже чем альтернатива на JSON+JS, но гораздо легче в поддержке.
no subject
no subject
no subject
Можно кровавых подробностей? Чем мнезия неприятна?
(disclaimer: я только интересующийся эрлангом, знаю пока мало, но книжки изучаю.)
no subject
Короче, это тяжело описывать - это можно только посмотреть - в эрланге вообще и мнезии в частности все другое. Жить с этим можно - но где взять например админов для мнезийных баз - я вообще не представляю. Или будете обучать сами с нуля, или этим будут заниматься разработчики.
no subject
no subject
Но веб-морду на ерланге писать это все-таки, по моим впечатлениям, не фонтан -- синтаксис мешает, особенно то что хэшей (т.е. hash_map) нету. Вот сам бэкенд, с интерфейсом на каком-нибудь JSON-RPC -- действительно приятно и легко.
no subject
no subject
no subject
если кому надо почитать, не дожидаясь, пока придёт заказ с амазона -- на аваксхоме находится ссылка на рапидшару с книжкой внутре