В своё время Ruby уделал всех
Язык Ruby и фреймворк Rails полностью поменяли способ создания веб-приложений. Они дали начало религии ценностей для сообщества программистов. Они первые предложили идею, согласно которой инструменты программиста должны быть оптимизированы для продуктивной и радостной разработки.
Именно они постулировали, что задача тестирования и доведения кода до работоспособного состояния лежит на разработчиках. Другие языки и фреймворки насмехались над таким подходом, пока он не начал завоёвывать популярность. После этого они стали включать принципы, присущие сообществу Ruby, в другие языки и фреймворки.
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/мес. Да, да – запросы обрабатываются за микросекунды на одноядерной машине.
Лидерство
По моему мнению, разница между просто открытым кодом и движением заключается в лидерстве, присутствующем в проекте. Короче, чтобы софт ежедневно улучшался, нужно, чтобы свою лепту в него вносили очень умные люди.
Движение 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, вот вам мой тьюториал.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий