Почему я ставлю на Elixir

https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f847b58#.mj05bf17k
  • Перевод
6 лет я создавал приложения на языке Ruby и фреймворке Rails. Я щупал всякие новые языки программирования по мере их выхода, но Elixir – первый из них, который меня действительно увлёк.

В своё время Ruby уделал всех


Язык Ruby и фреймворк Rails полностью поменяли способ создания веб-приложений. Они дали начало религии ценностей для сообщества программистов. Они первые предложили идею, согласно которой инструменты программиста должны быть оптимизированы для продуктивной и радостной разработки.

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

image

Ruby прошёл путь от скромного положения невразумительного языка до одного из самых популярных языков, в основном из-за фреймворка Rails и огромного лидерского потенциала таких людей, как DHH, Wycats, Aaron Patterson, Jose Valim и множества других. Но периодически, и тут и там начинают вылезать артефакты, оставшиеся из-за такого скромного старта языка.

Убегающая память


Зед Шо [Zed Shaw] в посте "Rails – это гетто" разглагольствует на тему проблем со сборкой мусора, из-за которых первые приложения на Rails перезапускались каждые 4 минуты.

Один из самых популярных серверов для Rails сегодня – это unicorn. Моё веб-приложение – это приложение для Rails, оно довольно простое, по сравнению с другими приложениями, которые я разрабатывал. Я перенёс его на сервер с 512 Мб памяти, и после нескольких дней работы мой unicorn съел всю доступную память и приложение начало тормозить.

Решение? unicorn-worker-killer. Не слишком отличается от более ранних решений.

Мой сервер способен обслужить два потока unicorn, забирающих большинство ресурсов, базу данных Postgres и несколько других приложений. Отзывается он, правда, довольно быстро, поэтому работу свою делает.

Параллелизм


Хотя я занимаюсь разработкой приложений для Rails уже несколько лет, я ни разу не использовал дополнительные потоки в приложениях для продакшена. Сам по себе Rails нормально работает с потоками, но по моим ощущениям, от них возникают одни лишь проблемы – я пробовал использовать их в Java, C++ и других ООП-языках.

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

Тестирование – главная парадигма сообщества Ruby, поэтому неудивительно, что большинство рубистов не трогают многопоточность, поскольку её практически невозможно тестировать, а её баги очень сложно воспроизводить.

Как и большинство нормальных разработчиков, я использую sidekiq или resque для обработки вещей в параллели. В Rails 2.2 добавили безопасность для потоков, но в Rails 4.2 добавили Active Job API, которое оказалось гораздо более полезным.

Но процессы, выполняемые в фоне, нужно выполнять в фоне. А критичные вещи нужно выполнять в главном процессе – чтобы можно было среагировать на ошибку или проследить, что все транзакции были успешно завершены, перед тем, как завершать задачу.

Скорость


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

Какое-то время выполнение функциональных и юнит-тесты у проекта, над которым я работал, занимало порядка 20 минут. Я использовал hydra для распределённых тестов, но мне всегда было сложно сделать так, чтобы тесты проходили (скорее всего, из-за слишком сложного и не особо красивого кода).

Даже запуск тестов занимал секунд 40. Вы когда-нибудь ждали 40 секунд, только чтобы увидеть: “syntax error, unexpected end-of-input, expecting keyword_end”, или ещё такую же ерунду? А я ждал.

Что делать? Zeus. Прекрасный gem, которая предварительно загружает всё необходимое для приложения и может загрузить (согласно описанию на github) любое приложение для Rails за секунду. Он мне нравится, и я рекомендую его всем.

Но как они достигли такого быстродействия? Просто написали его на Go.

Scala


Пару лет назад я обрадовался появлению Scala. Потом я начал её использовать – и ненавидеть.

У неё есть много концепций из функционального программирования. Фреймворк akka позволяет писать надёжные приложения. Она запускается в JVM, поэтому может использовать любую библиотеку из Java, а JVM очень хорошо обработана на предмет быстродействия.

Сам язык приятный. Но что меня остановило? JVM. Управление пакетами jar слишком сложное, если сравнить его с Rubygems и Bundler.

Есть, конечно, всякие решения: SBT, Maven, Ivy,- но все они заставляют меня морщится, когда мне нужно импортнуть чью-либо чужую библиотеку. Может, Ruby меня испортил, но управление пакетами в нём – одна из основных причин моей продуктивности.

Что меня ещё напрягало в Scala, так это что используемые мною библиотеки были написаны на Java людьми, чьи ценности и установки сильно отличались от моих.

Создание веб-приложения на Scala в фреймворке Play! выглядело так же, как создание веб-приложения на Java в фреймворке Play!, кроме чуть более простого синтаксиса и возможности поиска шаблонов. Хотя Rails сильно повлиял на Play!, разница между ними чувствуется интуитивно.

Экосистема Elixir


Управление пакетами через Mix

Впервые погрузившись в Elixir, я наткнулся на Mix. Это гибрид Bundler и Rake в Ruby. Что мне в нём так нравится – это то, что он не хуже, чем Bundler и Rake. Он и не сильно лучше, но планка поднята достаточно высоко и подняться до неё – это уже достижение.

Mix делает свою работу прекрасно, не мешается под ногами, и не заставляет вас возиться с XML.

Виртуальная машина Erlang

Elixir работает в виртуальной машине Erlang, и поддерживает почти все ценности сообщества Erlang. Elixir и Erlang гордятся фокусировкой на функциональном программировании, которое устойчиво к ошибкам и хорошо масштабируется.

Большинство обсуждений Elixir сводятся к следующим заявлениям:
  • на Erlang работает 50% сетей телекоммуникационных компаний. Когда у вашего телефона в последний раз был перерыв на «запланированное обслуживание»?
  • у WhatsApp, купленного за миллиарды денег, миллионы процессов работали на одном серваке, который поддерживал 450 миллионов пользователей – и всё это работало под управлением 32 инженеров

Эти же ценности близки и сообществу Elixir. Если вы, как разработчик на Elixir, используете супервайзеры из Erlang или http-сервер cowboy, вы не чувствуете, что предаёте свои ценности.

Веб-фреймворк Phoenix

На phoenix framework, очевидно, сильно повлиял Ruby on Rails, и создание веб-приложения для Phoenix выглядит очень похоже на создание приложения для Rails. Мне нравится роутер у Rails. А также ActionController, ActiveRecord, Rails Views и способ, каким вы можете программировать приложение. Мне нравится организация приложений в Rails.

Phoenix так похож на Rails, что вам покажется, будто вы делаете приложение для Rails, кроме того, что оно будет работать под Elixir и иметь все преимущества Elixir и виртуальной машины Erlang.

Кроме этого, он поддерживает WebSockets через каналы. Это позволяет вам легко использовать WebSockets, предоставляемые в Firebase.

А я говорил о том, что он быстр? Он быстр, как молния. Взгляните на логи с моего сервера на DigitalOcean стоимостью в $5/мес. Да, да – запросы обрабатываются за микросекунды на одноядерной машине.

image

Лидерство


По моему мнению, разница между просто открытым кодом и движением заключается в лидерстве, присутствующем в проекте. Короче, чтобы софт ежедневно улучшался, нужно, чтобы свою лепту в него вносили очень умные люди.

Движение Rails приобрело такой большой импульс, благодаря работе DHH, Aaron Patterson, Jose Valim, Wycats и кучи других. Не было такого, чтобы запустили первую версию Rails и работа встала.

Это всё старая привычка много работать – а построение грамотного сообщества требует большой работы. Jose Valim, Chris McCord, и все остальные члены основных команд Elixir-Lang и Phoenix работали и продолжают работать над процветанием их сообщества.

Веб ждут великие преобразования


Признайте – CRUD-приложения на сегодняшний день являются товаром. Следующий стартап «AirBnB для аренды кетчупа» скорее всего не выживет.

Победят те, кто примут изменения в технологиях. То, что в WebSockets, процессы и параллелизм в Phoenix и Elixir легко достижимы, и из-за них не надо поступаться лёгкостью программирования, просто меняет всё дело.

Я очень люблю Ruby on Rails. Он поменял способ создания веб-приложений в годах 2005–2014. Думаю, что Elixir и Phoenix произведут такой же эффект в годах 2015–2025.

Если вы уже хотите начать делать веб-приложения на Phoenix и Elixir, вот вам мой тьюториал.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 35
  • +14
    Я так и не понял чем Elixir лучше Erlang.
    • +4
      Потому что, по-моему, автор хотел сказать, что Феникс и Эликсир лучше, чем Руби и Рельсы.
      Эрланг тут не при чем.
      • +2
        Синтаксисом. Ну это субъективно конечно.
        • 0
          Субъективно синтаксисом все языки для BEAM (виртуальная машина Erlang) уделывает LFE. Только его на 90% один человек пишет в свободное время, поэтому с экосистемой большие проблемы.
          • 0
            Субъективно мне синтаксис LFE кажется многословным(хотя reader macro могут это поправить), местами уродливым(LFE WAT U DOING STOP IT MAH EYES R BLEEDING https://pbs.twimg.com/media/CJ4qaE7W8AAwOnD.png), местами очень неудобным(no name reuse in patterns). Очень приятный лисп для BEAM был joxa, но он заброшен.

            BTW, Elixir страдает от некоторой неконсистентности синтаксиса и смешивать его в одном проекте с erlang кажется довольно сомнительной затеей, и я говорю не об interop, а именно о его инфраструктуре в целом.
            • –5
              не рекомендуешь мешать эрланг и эликсир?

              Это же может быть приговор эликсиру. Разделение коммьюнити на модных гламурных хипстопидоров и бородатых инженеров, которые не могут работать вместе.
              • 0
                Я недостаточно хорошо с ним знаком, чтобы не рекомендовать, да и каких-то значимых проблем быть не должно по идее.
                Сомнения мои из-за того, что у него есть помимо языка и библиотеки есть еще и инфраструктура, и как ее использовать вместе со сложившейся инфраструктурой э-га — непонятно. Свой менеджмент проектов, свой логгер, свой шелл — мне пока не очень понятно даже как это просто деплоить, не то что, как это в эрланговый проект включать.

                А вообще, про использование эликсира из эрланга у тебя должно быть уже больше понимания, чем у меня, ты же собирался попробовать использовать Ecto.
                • 0
                  пока никак. Из-за того, что я не понимаю, как использовать эликсир вместе с эрлангом, я пока не решил даже на пилотный проект втыкать эликсир.
                • 0
                  А насчет разделения коммьюнити — мне кажется очевидным, что не смогут. Но может быть, какой-то процент хипстопидоров одумается и отрастит бороды.
          • +1
            наличием ORM на самом деле.

            В силу определенной специфики эрланга, сделать на нем удобный ORM чертовски сложно.

            Всё остальное, честно говоря, так себе различия.
            • 0
              строки, мапы, настоящий орм, настоящий пакетный менеджер
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  для начала вокруг Эликсира проталкивается лживый хайп по поводу какой-то связи между эликсиром и руби. При том, что никакой связи то нет
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Учитывая, что разрабатывает Elixir один из ключевых разработчиков Rails и работник ruby-центричной компании platformatec… Даже если ему очень захотелось бы не оставить никакой связи с языком, у него бы это не получилось. А если серьезно, ряд элементов синтаксиса у него явно позаимствован из руби.
                      • 0
                        string interpolation разве что.

                        Всё остальное больше обманка. Можно было сделать язык частично совместимым с руби, что бы частично шарить минимальный код (например, какую-нибудь авторизацию), но он отказался.

                        В итоге получился очень сложный язык, который непонятно как интегрируется в основную экосистему и уже оттягивающий силы. Зачем-то вместо реюза кода из эрланг народ уже понесло писать свои json библиотеки и прочий подобный стафф.
                        • +1
                          Своя json библиотека нужна для того, чтобы с помощью протокола можно было добавлять decoder/encoder для своих типов.
                • +3
                  Забавно что автор поставил unicorn который славится своей текучестью и потом аргументировал тем что rails утекает.
                  • –8
                    Еще сначала сказал «в свое время Ruby уделал всех», а потом стал расписывать, какое Rails говно.
                    Собсна, 99% кодеров на рельсах до сих пор думают, что это и есть ЯП.
                    • +8
                      Ага, 99% статистики про «99%» берется с потолка. За последние 4 года провел пару сотен собеседований с рейлс-разработчиками, ни один из них не считал рельсы языком.
                    • +1
                      Полностью поддерживаю. Чуть больше года назад все наши рельсовые приложения перевели с пумы и юникорна на пассажир и с тех пор проблем реально не видели. Это идеальной решение для работы нескольких приложений на одном сервере, которое может похвастаться единством глобальной конфигурации, но раздельным контролем состояния приложений и общим логом, который, при желании, можно настроить чрезвычайно гибко. С памятью пассажир работает очень хорошо, ни разу не было чтобы на одно приложение скушалась вся память если есть параллельно работающие приложения.
                      А что касается сабжа, может у Elixir и есть будущее, но как правило практически все определяется сообществом — если сообщество будет активно развиваться, мы получим в итоге хороший инструмент. А пока рельсы живы, здоровы и развиваются, реальные боевые приложения на других платформах писать пока не тянет.
                    • +12
                      Самая шикарная фраза:
                      Есть, конечно, всякие решения: SBT, Maven, Ivy,- но все они заставляют меня морщится, когда мне нужно импортнуть чью-либо чужую библиотеку. Может, Ruby меня испортил, но управление пакетами в нём – одна из основных причин моей продуктивности.

                      Если говорит о затратах на управление пакетами в проекте, то на это у меня уходит не более 1% времени. Если у автора управление пакетами это одна из главных причин продуктивности, то мне кажется что-то в этом не так.
                      • +4
                        Самая шикарная — это «Но как они достигли такого быстродействия? Просто написали его на Go».
                      • +1
                        кроме чуть более простого синтаксиса и возможности поиска шаблонов

                        except with slightly better syntax and the ability to do pattern matching.


                        Я долго пытался понять, какие шаблоны можно искать в Play… Такие вещи как паттерн матчинг лучше не переводить.
                        • +13
                          Ну почему же сразу не переводить, есть же общепринятый перевод — «сопоставление с образцом»
                        • +4
                          Тестирование – главная парадигма сообщества Ruby, поэтому неудивительно, что большинство рубистов не трогают многопоточность, поскольку её практически невозможно тестировать, а её баги очень сложно воспроизводить.

                          После этих строк, перестал читать.
                          • +2
                            Я 85% времени трачу, на то, чтобы понять, что делать. 10% времени трачу на то, чтобы что-то сделать. Остальное утекает, ruby же.
                            Каков процент стартапов, которые доживают до того момента, когда нужно задуматься о производительности? Какой процент стартапов из этих задумывается о производительности из за кривых рук?
                            • +4
                              Тут вопрос не в кол-ве успешных стартапов, а в том, что в ближайшее десятилетие рост вычислительных мощностей будет достигаться за счёт увеличения кол-ва ядер. Представьте, допустим через 5 лет, 128-ядерный процессор на самом дешёвом VDS. Как использовать его наиболее эффективно? Многие задумываются об этом уже сейчас…
                              Поэтому знание функциональных языков программирования становится практически обязательным для любого уважающего себя программиста.
                              • 0
                                Некоторой части стартапов вполне хватит и одного процессора на веб-интерфейс (а в статье, вроде, веб-разработка в основном рассматривается).
                                Помимо многопоточности вопрос использования 128 процессоров можно решить запуском нескольких процессов. Эффективность будет меньше, но вполне вероятно, что она будет приемлемой для конкретного проекта.
                                • 0
                                  Зачем тут вообще привязываться к стартапам? Некоторой их части и CMS какой-нибудь вполне хватит. Вопрос не в этом, а в том, в каких проектах лично Вам, как программисту, будет интересно участвовать. Суть нашей работы выбирать инструменты, лучше подходящие под задачу. Но осознанно выбирать мы можем только из тех инструментов, с которыми знакомы.
                                  Поэтому на мой взгляд тут главный вопрос в том, интересно ли Вам иметь в своём личном арсенале инструмент, хорошо подходящий для эффективной работы в многоядерных системах и имеющий проверенные возможности для обеспечения отказоустойчивости. Если неинтересно, то ok, никто ж не заставляет. А если интересно, то имеет смысл уделить время изучению Erlang и Elixir.
                              • 0
                                Каков процент стартапов, которые доживают до того момента, когда нужно задуматься о производительности?
                                производительности программиста — высок, приложения — нет
                                • НЛО прилетело и опубликовало эту надпись здесь
                                • 0
                                  Статья по ссылке немного устарела, даже если следовать ей всеравно могут быть ошибки (эликсир 1.1.0)
                                  Лично я сделал git checkout d59bebd. Так как среди билдов этот последний был удачным (https://travis-ci.org/phoenixframework/phoenix/builds), если же делаю чекаут v0.8.0 как в статье или последней (v1.0.3) версии появляются ошибки.
                                  из readme:
                                  $ cd installer
                                  $ mix phoenix.new <cloned_phoenix>/splurty --dev
                                  $ cd <cloned_phoenix>/splurty
                                  $ mix phoenix.server
                                  тогда все работает
                                  • –1
                                    Язык Ruby и фреймворк Rails полностью поменяли способ создания веб-приложений.

                                    Очень сильное утверждение. Мне кажется тот же Python повлиял не меньше и у него не течёт память… :)
                                    • 0
                                      Я очень люблю Ruby on Rails. Он поменял способ создания веб-приложений в годах 2005–2014. Думаю, что Elixir и Phoenix произведут такой же эффект в годах 2015–2025.

                                      Эх, честно сказать я ничего революционного в Ruby on Rails не увидел. Хотя, не исключаю, что мое мышление устарело, а может потому, что я из Enterprise. Идеи Rails мне нравятся, но революции в этом нет и сказать, что он поменял способ создания веб-приложений в годах 2005–2014 я не могу. Сейчас J2EE очень не плохие идеи имеет, но и они не революционны. Так что сомневаюсь, что Elixir и Phoenix что-то изменят. Просто будет один из вариантов для студентов что-то попробовать «простое» и новых идей для J2EE.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.