Давненько я не выбирался на IT-мероприятия, так что продолжу традицию делиться впечатлениями. Как следует из заголовка она была исключительно про Erlang, причем в самых разных его проявлениях. Недавно я написал пару статей про него, можно найти по соответствующему тегу. Конференция была всего на пол дня, так что пост получится явно небольшой - много времени не займет ;)
Организация
Мероприятие проводили совместно Erlang Solutions (международная организация, которая регулярно проводит подобные Erlang-мероприятия, сертификации и т.п.) и Яндекс. Проходило все в двух шагах от офиса Яндекса, плюс они же занимались собственно всеми организационными вопросами. Единственный представитель Erlang Solutions видимо не знал что в Москве бывают пробки и сильно опоздал, к слову у меня на телефоне его фотка нашлась, заодно можно оценить масштабы мероприятия (весь единственный зал):
Конференция по задумке должна была быть полностью на английском, без перевода, так как якобы трансляцию могли смотреть и не русские. Но по факту докладчики были к этому не готовы, у примерно трети докладчиков был английский с кошмарным акцентом, не говоря уже о длинных паузах "э-э-э" пока вспоминались подходящие слова.
Еще из косяков к началу конференции никто не удосужился проверить звук и удаленный переключатель слайдов.
А в остальном все ок, простенько и со вкусом. Едем дальше.
Доклады
Яндекс
- В Яндексе всего три Erlang-программиста, кажется все присутствовали
- Используют свой форк ejabberd примерно пятилетней давности для их мессенджера и пуш-уведомлений:
- С момента своего создания изменения из основной ветки развития не мерджились и обратно выкладываться в opensource не собираются из-за "сильной интеграции с другими сервисами Яндекса"
- Для хранения постоянных данных используют MongoDB, на вопрос почему именно докладчик так честно ответил "не знаю"
- Основная часть доклада ушла на рассказ об оптимизациях внутри самого ejabberd, реализованных в их форке, в частности:
- Добавили проверку на то, жив ли процесс перед тем как отправлять ему сообщение, изначально ejabberd в этом плане был более оптимистичен и их это по непонятным причинам не устроило.
- Уменьшили объем используемой оперативной памяти за счет "ленивой подгрузки" части данных, которые редко используются. Из зала, кстати, кто-то добавил что у аналогичного форка от Erlang Solutions повсеместное использование бинарных строк вместо обычных дало очень ощутимую экономию оперативной памяти.
- И, кажется, объединили принимающий и отправляющий сообщения процессы в один.
- На вопрос о цифрах выдали только порядки: несколько десятков серверов обслуживают несколько сотен тысяч пользователей онлайн.
Fedora Project
Обсуждался вопрос сильного "отставания" доступных по-умолчанию в Linux-дистрибутивах версий Erlang, да и не только Erlang, от последней стабильной. Я думаю очень актуальный вопрос для тех, кто занимается продажей коммерческого софта для Linux, или для тех, кто занимается сборкой и поддержкой пакетов для opensource проектов.
Erlang сделан так, что подход "все свое ношу с собой", существенно проще и удобнее, чем управление зависимостями. Хотя докладчик приводил пример, что CouchDB как раз использует альтернативный подход требования точных версий зависимостей и у них в Fedora были большие заморочки с тем, что они обновили JavaScript-движок на одну версию выше, чем от которого зависела последняя версия CouchDB. Я так и не уловил как в итоге эту ситуацию решили, наверное пришлось оставить в репозитории две версии зависимости или дождаться и обновления CouchDB.
Mochi Media
Вместо рассказа о mochiweb речь шла о различных вариантах как можно реализовать случайный выбор элемента из списка и их слабых и сильных сторонах. Причем для примера использовался не реальный проект, где они подобным занимаются (баннерная сеть), а IRC-бот написанный для развлечения. Да и к Erlang практически никакого отношения, единственной что узнал полезного: стандартный модуль random написан по не самому удачному алгоритму, созданному в начале 80-х, и если это сколько-либо критично для приложения - лучше вместо него использовать crypto или сторонние библиотеки.
Макс Лапшин
Докладчик является, пожалуй, самым активным участником российского Erlang-сообщества, известен в узких кругах как автор Erlyvideo, opensource решения для потокового вещания видео. Рассказывал про какой-то другой проект, в частности о парсере протокола FIX, использующегося на фондовых биржах и отличающегося огромной спецификацией с более чем сотней типов сообщений. Основная идея доклада: если нужно написать много однотипного кода, его лучше сгенерировать, чем копипастить.
К счастью, авторы этого протокола заботятся о разработчиках и публикуют спецификацию в виде XML-файла, который Макс предлагает парсить и генерировать на его основе необходимые .erl файлы, не дерево синтаксиса, а прямо текстовые .erl файлы. В конкретно этом случае ему нужно было из proplist-ов создавать record'ы, а сам парсинг сообщений он решил написать на C. Хотя мне кажется эту конвертацию тоже можно было бы убрать в C.
Алекс Гунин
Это был единственный доклад на 80% на русском, так как попытка начать его на английском закончилась полным провалом. Хотя заголовок у доклада был самый, пожалуй, интересный - "как сделать Erlang по-настоящему распределенным и отказоустойчивым". Основная идея была использовать часть распределенной СУБД Riak, отвечающую за распределение и поиск данных в кластере (Riak Core), для маршрутизации простых Erlang сообщений и по аналогии с несколькими репликами данных запускать несколько копий одинаковых процессов. Для реализации этой затеи они написали совместимые со стандартными модули gen_server2, gen_fsm2 и т.п. (что, кстати, плохая практика - из-за таких названий можно легко столкнуться с конфликтами в пространстве имен модулей, например в RabbitMQ и каком-то еще популярном проекте тоже есть gen_server2, как-то сталкивался)
Задумка явно толковая и думаю для многих систем актуальная, но подробностей очень мало, плюс докладчик очень смутно излагал свои мысли даже на русском. Он не сказал для какой компании он все это разрабатывал, но пообещал выложить саму систему маршрутизации сообщений в opensource. Когда и где - не ясно.
Лев Валкин
Это был последний доклад, где я присутствовал, в оставшейся секции из трех докладов мне совсем ничего не приглянулось, но зато этот мне больше всего понравился. Думаю в первую очередь так как Лев косвенно пропагандировал очень близкую мне тему использования Erlang для создания интерактивных веб-сайтов. Большинство докладов были все же про другие предметные области. Раньше про его компанию Echo ничего не слышал, но список клиентов на главной у них солидный, надо будет почитать на досуге.
Сам доклад был про выбор и оценку языков программирования и связанных платформ по относительно объективным критериям (сообщество, ассортимент opensource библиотек, возможности в тестировании, интроспекции и дебаге, плюшки вроде горячей замены кода и пр.). Правда в итоге все свелось к тому, что главное, чтобы разработчикам нравилось что они делают - иначе как бы не была объективно хороша та или иная технология все равно получится черти что :)
Изначально Лев планировал доклад на тему Erlang vs node.js, но её забраковали организаторы, видимо за холиварность. В итоге она все же местами затрагивалась, да и вопросы после доклада в основном были по ней.
Основные моменты:
- Повторное использование кода между серверным JavaScript и клиентским - в большинстве случаев миф.
- Легко найти серверного node.js-разработчика, так как все и так уже знают JavaScript - тоже миф, клиентская разработка концептуально сильно отличается от серверной, намного больше node.js-разработчиков приходит с других серверных платформ, а не с клиентского JavaScript.
- node.js хоть и сильно проигрывает Erlang по ряду объективных показателей применительно к веб разработке, благодаря своей популярности именно среде молодых веб-разработчиков (во многом благодаря вышеизложенным мифам) сильно угрожает популяризации Erlang в этой же самой среде.
Свое мнение про JavaScript в целом и node.js в частности оставлю за кадром, недавно в одном из постов высказывался уже на эту тему.
