Язык Erlang известен не очень широко, хотя это довольно интересная технология, очень сильная в своей нише. Последние несколько лет Erlang все чаще применяется в веб-разработке.
Отношение к Erlang противоречивое – есть как убежденные сторонники, так и суровые критики. Однако мало кто использует его в разработке. Так что специалистов, которые могут хвалить или ругать этот язык, опираясь на собственный опыт применения, совсем немного.
В компании Wargaming Erlang применяется более 3 лет. Есть около десятка разработчиков и несколько проектов, работающих под большими нагрузками. И в этой статье мы поделимся своим опытом и видением Erlang.
Как все началось
В Wargaming используется микросервисная архитектура, где разные сервисы взаимодействуют между собой как по HTTP-протоколу, так и по AMQP. Поэтому активно используются сервера RabbitMQ.
Можно сказать, с RabbitMQ все и началось. И хотя программисты о Erlang еще не знали, но архитекторы и DevOps уже нарабатывали опыт, разбираясь, почему где-то упал RabbitMQ, что можно извлечь из его логов и crash dump; и что нужно сделать, чтобы он не падал :)
Надо сказать, что наши архитекторы на тот момент уже давно питали симпатии к Erlang, но не внедряли его как язык разработки, пока не появились веские причины для этого.
Не секрет, что наши игровые сервера работают на движке Big World, где игровая логика пишется на Python (Python был и остается основным языком разработки в компании). Изначально через эти сервера работал и внутриигровой чат. Но на какой-то момент тратить ресурсы серверов (которых и так не хватало) на чат, стало невозможно.
Чат World of Tanks тесто связан с игрой, поддерживает множество специфических функций. Поэтому для него было необходимо собственное решение. Оно, конечно, должно было быть кластерным, так как один сервер нельзя масштабировать под имеющиеся и планируемые в будущем нагрузки. Вполне логично, что для такого проекта был выбран Erlang. Тогда в компанию и пришел первый Erlang-разработчик.
Как все продолжалось
Помимо игровых серверов, у нас есть множество веб-сервисов (вроде регистрации и авторизации игроков, платежей и т.п.). Первоначально это все было написано на Python/Django, и в результате быстрого роста числа игроков в вебе начались проблемы.
Тогда мы начали использовать Twisted. Но и разработчики, и архитекторы считали его слишком сложным, а разработку на нем слишком дорогой.
В качестве замены архитекторы предлагали использовать Erlang, но у руководства возникли обоснованные сомнения – откуда взять достаточно Erlang-разработчиков, ведь это не самая популярная технология.
Между тем, прототипы, написанные на Erlang, показывали хорошую производительность в бенчмарках, а Twisted продолжал причинять боль. И архитекторы пошли дальше прототипов, сделали и запустили один небольшой веб-сервис на Erlang. Он был написан за пару недель усилиями одного архитектора и оказался удачным.
Потом был второй проект, третий. Компания начала поиск Erlang-разработчиков, а наши Python’исты без труда осваивали новый язык (для некоторых это было проще, чем разобраться с Twisted).
На сегодняшний день в компании десяток разработчиков, которых можно назвать Erlang-разработчиками – они большую часть кода (или даже весь) пишут на Erlang. Некоторые из них уже несколько лет пишут на Erlang, а кто-то только перешел с Python.
Работы в вебе у нас много. Растет количество игр, которые выпускает Wargaming. Мы переходим от специализированных (под конкретную игру) сервисов к универсальным. Также стартуют новые проекты, многие из которых пишутся на Erlang. В вакансиях мы чаще ищем Python-разработчиков (основной язык программирования в нашей компании), но упоминаем, что знание Erlang будет плюсом :)
В результате нам удалось собрать команду сильных Erlang-разработчиков. Среди них, например, Сергей Прохоров, чей патч приняла команда Erlang/OTP. Так что теперь в виртуальной машине Erlang есть немного кода Сергея.
Мнения разработчиков
Имея внутри компании достаточно много Erlang-разработчиков с разным опытом, мне удалось собрать широкий спектр мнений об Erlang. Любопытно отметить разницу в восприятии языка между опытными и начинающими разработчиками.
Опытные в целом относятся к Erlang позитивно. И это не удивительно, иначе они бы не писали на нем несколько лет и не стали бы опытными :)
Начинающие относятся по-разному. У них больше критики и недовольства. Это тоже не удивительно, потому что в сравнении с Python, Erlang заметно беднее и по выразительности, и по инфраструктуре, и по богатству библиотек.
Начнем с общих моментов, с которыми согласны все наши разработчики:
- Erlang показывает хорошую производительность в вебе, измеряемую числом запросов в секунду. Добиться аналогичной производительности на Python дольше, сложнее и дороже.
- Erlang язык узкоспециализированный. Не стоит пытаться решать на нем любые задачи.
Плюсы Erlang, общее мнение:
- Хорошая модель многопоточности, которой удобно пользоваться. Модель акторов и асинхронность позволяют легко писать эффективный многопоточный код.
- За 20 лет использования в нагруженных проектах сформировались стандарты и шаблоны, собранные в OTP-фреймворк. С ними проще строить сложные, но стабильные и надежные системы.
- Erlang умеет использовать все доступные ядра. Нет необходимости запускать отдельный экземпляр сервиса для каждого ядра.
- Низкий порог вхождения. Язык простой, изучается быстро (однако тут есть некоторые подводные камни, о которых будет написано ниже).
Плюсы, которые видят начинающие разработчики:
- Замкнутая экосистема, проекту не нужно ничего из внешнего мира.
- Не нужно внешнее in-memory хранилище (Radis, memchached), можно держать кэш прямо в оперативной памяти сервиса.
- Не нужно запускать несколько экземпляров сервиса для каждого ядра, под внешним супервизором, со своей конфигурацией. Один сервис может использовать все ядра, и имеет свою гибкую систему супервизоров.
- Меньше экземпляров сервисов – меньше общения между ними по HTTP или AMQP. Гораздо удобнее общаться между процессами внутри одного узла.
- Проще разрабатывать распределенные системы. У Erlang есть свои средства для построения кластеров и общения между узлами.
Плюсы, которые видят опытные разработчики
- Функциональная парадигма, иммутабельные структуры данных.
- Удобно мониторить сервис в реальном времени, искать и устранять проблемы прямо на работающем узле.
- Можно менять конфигурацию без перезагрузки сервиса.
Минусы, общее мнение
- Библиотек мало, еще меньше – хороших. Многое нужно писать самим или дорабатывать.
- Ограниченный синтаксис языка. Иногда не хватает более удобных синтаксических конструкций. Например, не помешала бы конструкция let, чтобы вводить области видимости. Докучает необходимость создавать переменные с числовыми суффиксами: Var1, Var2, Var3.
- Язык консервативный и развивается очень медленно. Например, тип map внедряли несколько лет (и до конца не доделали).
- Медленно развивается инфраструктура для веба, нет веб-фреймворка.
- Язык ориентирован на более низкоуровневое применение, чем то, что привычно Python/Django или Ruby/Rails-разработчику.
Минусы, которые видят начинающие разработчики
- Строки реализованы ужасно, средств для работы со строками очень мало. Опытные разработчики вообще строками не пользуются, и поэтому забыли про такую проблему :)
- Слабая стандартная библиотека, мало возможностей. Это особенно заметно на фоне Python. Несогласованности в стандартных модулях (названия функций, порядок аргументов, возвращаемые значения).
- Функциональная парадигма, иммутабельные структуры данных. Что для опытного разработчика плюс, для начинающего, не знакомого с парадигмой – минус. Это требует отдельного изучения.
- Тяжело читать сообщения об ошибках.
Минусы, которые видят опытные разработчики
- Нет хороших инструментов для управления зависимостями и сборки пакетов. Rebar3 и hex – движение в нужную сторону, но они еще сырые и не приняты широко.
- Релизы устроены сложно и решают не те задачи. Например, они решают задачу горячего обновления, а это не нужно веб-разработчику. Правильнее строить сервис так, чтобы он безболезненно переживал остановку одного узла.
- Синтаксис конфигов не удобен DevOps. Честно говоря, он не удобен и самим разработчикам. Лучше описывать конфигурацию в более простых форматах, например, ini.
Еще несколько индивидуальных мнений
- Python-разработчику проще освоить Erlang, чем Twisted, не смотря на то, что это совсем другой язык. Проекты на Erlang проще, разрабатываются быстрее и ведут себя надежнее, чем аналогичные на Twisted.
- Сообщество Erlang-разработчиков маленькое и не очень активное. Каждая команда живет в своем проекте. Мало кто обменивается опытом и шарит знания коллегам из других компаний. Обычная ситуация, когда каждый разработчик пишет свой набор библиотек, который используется только в его проекте.
- Есть крупные open source проекты, как Cowboy или Riak, но нет проектов, вокруг которых сложилось бы активное сообщество.
- Виртуальная машина Erlang хороша, но сам по себе язык – слишком консервативный, не стремится к развитию. Поэтому активное развитие сейчас идет в рамках новых языков для этой виртуальной машины, как, например, Elixir.
- Erlang и Python неплохо дополняют друг друга, компенсируют слабые стороны. Правильно сочетать их вместе в одном проекте. Бизнес-логику, ORM, работу с базой лучше делать на Python, а многопоточную обработку данных, связь между сервисами, фоновые процессы – на Erlang.
- Erlang обладает ужасным синтаксисом, который заставляет страдать :)
Что получается в сухом остатке?
В целом разработчики с удовольствием критиковали Erlang, и минусов находили больше, чем плюсов. Это не удивительно, ведь к достоинствам технологии быстро привыкаешь, считаешь их само собой разумеющимся, а недостатки продолжают раздражать и привлекать внимание.
Однако у нас в компании разработчики сами выбирают язык для проектов (конечно, из списка одобренных архитекторами :)), это решение не навязывается сверху. И раз уж они пишут на Erlang, значит он не так плох.
На сегодняшний день в нашем вебе используются Python 2.7, Python 3.5 и Erlang. Архитекторы не против попробовать и другие варианты: язык Go, один из JVM-языков, еще что-то – но пока желающие нашлись только на Elixir, и об этом ниже.
Коварный порог входа
Наверняка многие слышали, что у Erlang низкий порог входа, и разработчик уже через 2 недели знакомства с языком может писать код для продакшена.
Это правда, но не вся. Язык действительно простой и легко изучается, но есть и подводные камни.
Во-первых, «детские проблемы» на которых многие неопытные разработчики спотыкаются, а опытные, научившись их решать, забывают. Классический пример – получить deadlock в gen_server. Это случается почти у всех. Своего рода ритуал вхождения в клуб :) Из той же песочницы проблема понимания, что строками пользоваться не нужно, а использовать только binary. Этого правила легко придерживаться в своем проекте, но, к сожалению, в сторонних библиотеках может быть по-всякому, и к этому нужно быть готовым.
Во-вторых, есть и совсем не детские проблемы. И первая из них – недостаток информации. По Erlang написано всего несколько хороших книг. Большинство из них описывают язык как таковой, а не применение его для решения прикладных задач. Многие важные вопросы не описаны вовсе, ни в книгах, ни в документации.
Какие инструменты использовать для сборки проекта? Как мониторить работающий узел? Как обнаружить переполнение mailbox? А другие варианты утечки памяти? Как находить узкие места, мешающие масштабировать систему?
Какие библиотеки использовать? Их, с одной стороны, мало. С другой – популярные библиотеки имеют много форков. И не понятно, что это за форки, чем отличаются, как поддерживаются. Те, кто искал драйвер для работы с MySQL, хорошо понимают эту проблему :) И это мы еще не взялись за распределенные системы – отдельный мир с кучей своих нюансов.
Обо всем этом можно узнать только от другого опытного разработчика. Поэтому важно, чтобы они всегда были в команде.
Несколько слов об Elixir
Существует несколько языков, которые компилируются в байт-код Erlang и работают на виртуальной машине Erlang. Самый популярный из них – Elixir.
Несколько лет назад на Erlang обратили внимание Ruby/Rails-разработчики. Они искали решение проблем с производительностью, характерных для Rails. Проблемы с производительностью решились, но все остальное в Erlang им не понравилось. И не удивительно, из мощного высокоуровневого языка с богатейшей инфраструктурой они попали в суровый низкоуровневый мир.
Ruby/Rails-разработчики быстро поняли, что так жить они не хотят, и начали строить для себя более комфортную среду. Результатом их усилий стал язык Elixir и веб-фреймворк Phoenix, у каждого из которых есть активное сообщество. За 3 года они сделали больше для веб-разработки, чем в Erlang было сделано за 10 лет.
Об Elixir, как и об Erlang, мнения противоречивы. Одни считают его легко читаемым, лаконичным и мощным. Другие – сложно читаемым и непродуманным. Консервативные Erlang-разработчики относятся к Elixir прохладно. А те, кто пришел в Erlang из Ruby или Python, принимают Elixir с любопытством.
Плюсы языка:
- Богатая стандартная библиотека;
- Высокоуровневый веб-фреймворк Phoenix;
- Хорошая инфраструктура: инструменты сборки, менеджер пакетов, библиотеки;
- Хорошая документация;
- Активное сообщество.
Минусы:
- Язык молодой, не накоплен опыт в индустрии;
- Знание Erlang все равно нужно, слишком тесная связь между этими языками;
- Низкий bus-фактор.
Сообщество занято инфраструктурой, библиотеками и фреймворком, а ядро языка разрабатывается небольшой командой. Есть риск, что если эта команда потеряет финансирование, и ее никто не заменит, то язык перестанет развиваться и поддерживаться.
В вебе Wargaming прототип одного из будущих сервисов делают на Elixir. Посмотрим, как он себя покажет.
Таково мнение наших Erlang-разработчиков. А что думаете вы? Что именно в языке вас привлекает, а что – мешает работать и попросту портит кровь? Поделитесь в комментариях! Расскажите о своем опыте работы с Erlang и реализованных проектах.
Спасибо за внимание,
Юрий Жлоба
Веб-разработчик в Wargaming
Автор: Wargaming
