Почему Erlang — язык для очень специфичных задач

27 марта 2015

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

На Erlang я писал почти два года, писал много, писал за деньги. Это очень хороший язык. Erlang используется во многих компаниях, в том числе WhatsApp, Яндексе, Facebook и других. На Erlang написано немало хороших open source проектов — Riak, RabbitMQ, Couchbase, CouchDB, ejabberd. На Erlang написана библиотека riak_core, у которой нет аналогов, если верить @sum3rman, а я ему в таких вопросах доверяю :)

Сам язык имеет ряд примечательных особенностей. Это один из немногих функциональных языков, получивших достаточно широкое распространение. Один из немногих, в которых есть горячее обновление кода и возможность открыть REPL в работающем приложении, чтобы разобраться, что прямо сейчас происходит в кишках. Возможно, единственный язык, программы на котором будут обслуживать 10 тысяч TCP-соединений, не требуя от программиста особо приходить в сознание. Модель акторов, реализованная в Erlang, оказалась весьма удачна для написания многопоточных приложений. Не даром ее пытаются (с сомнительным успехом!) слизать в Akka и Cloud Haskell.

Я искренне считаю, что любой бэкенд разработчик должен в обязательном порядке изучить Erlang и написать на нем как минимум простенькую REST-обертку к PosgreSQL. Чтобы просто посмотреть на то, как выглядит правильная модель акторов, безо всяких там футур и блокирующих вызовов.

Erlang, конечно, имеет свои недостатки. Довольно необычный синтаксис. Баги в виртуальной машине. Лично у меня вызывает сильные опасения использование динамической типизации в проектах серьезнее «сходил в базу, сгенерил json». Назвать Dialyzer человеческим решением может только тот, кто никогда не писал на Haskell и Scala. Инклуды и макросы в третьем тысячелетии — по-моему, просто позор. Но, на самом деле, все это мелочи.

Настоящих, совершенно непростительных, проблем у Erlang две.

Во-первых, библиотеки. Ладно, если бы их было просто мало. В конце концов, можно подобрать ту СУБД, для которой есть клиент, а вместо AWS SDK вызывать консольный клиент. Но проблема в том, что с теми библиотеками, которые есть, творится полный бардак. Из недавнего — чем ходить по HTTP неясно, а клиент для MySQL в очередной раз пишется с нуля. Все это в виде кучи форков, автор каждого из которых исправил те баги, на которые натыкался сам. Одной библиотеки, где исправлено все, просто нет. Форки эти зачастую оказываются несовместимы между собой, и раскиданы по всему GitHub. К тому же, Rebar работает с зависимостями из рук вон плохо. Не собирается проект? А ты попробовал почистить каталог debs?

Во-вторых, Erlang медленный. Вроде как кто-то где-то пытается сделать JIT компилятор, но я с трудом представляю, как он будет работать, не сломав при этом гарантии по равномерному распределению процессорного времени между акторами. Воспользоваться в узких местах библиотекой на Си тоже так просто нельзя, так как она может повесить работу всего приложения, а то и вовсе уронить всю виртуальную машину. Эта проблема, как, в общем, и проблема с библиотеками, решается в мире Erlang написанием куска приложения на каком-нибудь другом языке, который будет взаимодействовать с кодом на Erlang по TCP или еще как-то.

В действительности, Erlang хорошо делает одну вещь, и только одну. Берет данные из одного места и кладет в какое-нибудь другое. Как только возникает потребность сделать что-то большее, например, закодировать 100 Мб JSON’а, или смасштабировать картинку, все сразу становится очень плохо. Особенно если с вашим приложением одновременно работает больше сотни человек. Поэтому не верьте, если вам говорят, что Erlang подходит для веба, он не подходит.

Усугубляется проблема еще тем, что многие стартапы пишутся на Erlang, потому что это модно, а не потому что он им подходит. Если WhatsApp построил на Erlang распределенное, отказоустойчивое, высоконагруженное приложение, значит и мы сможем. У нас как раз высокие нагрузки, нужно очень быстро матрички перемножать! Ну а потом, когда уже слишком поздно, никто не станет «плодить зоопарк языков программирования» в проекте. Или переписывать программу, например, на Scala. Некогда, фичей еще целый вагон нужно сделать, и вообще в JVM же stop the world!

Итак, краткий ответ на вопрос «почему я сейчас не пишу на Erlang» — потому что, по моему мнению, этот язык хорошо подходит для довольно узкого класса задач, и прямо сейчас я занимаюсь задачами, которые к этому классу не относятся. Если вам нужно написать что-то, похожее на socks5-прокси или распределенную базу данных, Erlang, вероятно, будет неплохим выбором для решения этой задачи. Если же вам нужен более универсальный инструмент, на котором можно еще и матрички перемножать, писать веб, использовать Amazon SDK, писать GUI, а также под Android, экспортировать отчеты в Excel, или рисовать диаграммки, и при всем при этом хочется ФП, присмотритесь лучше к Scala, ну или Clojure хотя бы.

Метки: , .

Подпишись через RSS, E-Mail, Google+, Facebook, Vk или Twitter!

Понравился пост? Поделись с другими: