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

Так как я несколько лет писал на Ruby и в предыдущих компаниях всегда присутствовали причины не осваивать новый язык, я решил прервать этот порочный круг и выбрал Elixir. Буквально за пару недель в одиночку удалось освоить язык и экосистему на достаточном для написания MVP уровня и развернуть OTP приложение в Docker на AWS.

К слову, опыта разработки на функциональных языках у меня было совсем немного и общие впечатления от использования Elixir в продакшене на данный момент только самые положительные[1]. Расширяя команду разработки, я стал задумываться, как в условиях ограниченности ресурсов мы можем работать продуктивно, тратить меньше времени на поддержку своего кода и больше фокусироваться на product delivery. И здесь, конечно, Elixir по сравнению с Ruby дает определенные преимущества для Backend разработчиков. А что с фронтендом?

Каждый раз когда я вижу или слышу слово JavaScript, невольно вспоминаются все те баги, которые за годы программирования я встречал именно из-за дизайна языка. function is not defined – наше все! И вот стартуя очередной проект, возник вопрос: есть ли лучшая альтернатива для решения frontend задач? Какой-нибудь относительной простой язык, желательно функциональный[2], не академический, а прагматичный, направленный на современный веб...

После продолжительного исследования просторов интернета сформировался следующий список:

  • TypeScript
  • ClojureScript
  • Elm
  • PureScript
  • ReasonML

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

TypeScript отпал по двум причинам - не функциональный, не несет каких-то новых архитектурных подходов. ClojureScript мне нравится своим сообществом, наличием библиотек и инструментария для многих задач, включая React Native, но не избавляет от runtime-исключений. И как раз решить эту проблему призваны Elm, PureScript, ReasonML. Т.е. если ваш код скомпилировался, вы можете быть уверены, что с довольно большой вероятностью у вас нет подобных ошибок.

Ни с одним из перечисленных языков я не был знаком, поэтому начал с самого первого – Elm. Посмотрел выступления автора языка Evan Czaplicki Let's be mainstream! User focused design in Elm, его коллеги Richard Feldman Teaching Elm to Beginners и воодушевляющий доклад на ClojuTRE, который вы можете найти в конце этого поста.

Все услышанное вызвало большой интерес и побудило меня в свободное время заняться изучением второго нового в этом году для себя языка – Elm.

В последующих постах я постараюсь достаточно лаконично описать базовые принципы и подвести промежуточный итог после внедрения Elm в продакшене на нашем проекте. При этом я не исключаю, что Elm может не понравится мне или команде, и мы продолжим искать святой грааль с PureScript, ReasonML или же вовсе вернемся к JavaScript / TypeScript / ClojureScript.

📖 Читать дальше: Выбор языка для проекта | 📚 Назад к оглавлению


  1. Конечно, не без нареканий. Возможно по прошествии какого-то времени напишу об этом отдельный пост. ↩︎

  2. Спасибо тебе, Elixir, за наставление на путь истинный. ↩︎