В октябре Github запустил actions, которые позволяют выполнять CI, не отходя от кассы, в которой этот самый код хранится. Это действительно очень удобно. Как только кто-то отправляет pull request, или просто загружает новые изменения на сервер, или что-то еще специальное (список событий, к которым можно прикрутить actions может быть найден в официальной документации), сборка запускается. Также поддерживаются запланированные повторяющиеся задачи (по принципу cron).

Можно создавать конвейеры действий, названные рабочими процессами (workflows). И все это прекрасно, и смахивает на светлое будущее — за исключением документации.

REPL

REPL в мире наколенной разработки расшифровывается как Read → Evaluate → Print Loop. Зачитали, выполнили, напечатали, и так много раз.

Ruby, как и многие другие языки, поставляется с собственной реализацией REPL под названием irb. Который, хотя и справляется с примитивными задачами, все-таки полностью удовлетворить запросы взыскательного разработчика не может. Но существует и гораздо более развитая альтернатива: pry.

OTP расшифровывается как Open Telecom Platform; так исторически сложилось, потому что платформа создавалась для нужд и на деньги Ericsson. Но, в принципе, это название имеет примерно столько же коннотаций с ее функциональностью, сколько и яблоки со среднего качества телефонами.

Основной отличительной характеристикой OTP по замыслу авторов является отказоустойчивость. Не многопоточность, не модель акторов, не богатые возможности pattern matching’а, даже не прозрачная кластеризация и не hot code upgrades. Отказоустойчивость.

Виртуальная машина эрланга на поверхностный взгляд устроена очень просто: есть куча «процессов» (не системных процессов, эрланг-процессов) с изолированной памятью, которые могут обмениваться сообщениями. Все. Вот, что говорил Джо Армстронг по этому поводу:

In my blog I argued that processes should behave pretty much like people. People have private memories and exchange data by message passing.
— Why I don't like shared memory

Обмен сообщениями внутри OTP очень прост: один процесс посылает сообщение другому (или группе других процессов), синхронно, или асинхронно. Но для этого необходимо знать, кому эти сообщения посылать. То есть менеджером обмена выступает отправитель. Но что если мы хотим просто слать broadcast и дать возможность всем заинтересованным процессам подписаться на это сообщение?

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

Но, как это всегда бывает в нашем жестоком мире, в любой бочке пользы — без ложки не обойтись. По сути, директивы @spec дублируют код объявления функции. Ниже я расскажу, как двадцать строчек кода помогут объединить спецификацию и объявление функции в конструкцию вида

defs is_forty_two(n: integer) :: boolean do
  n == 42
end

Спецификации сигнатур функций (Typespecs)

Эликсир позаимствовал из Эрланга многое. Например, оба — языки с динамической
типизацией (что прекрасно, что бы вам там категоричные строгие типы в касках
не говорили). При этом, в обоих языках присутствуют расширенные возможности для
проверки типов, когда это надо.

Вот введение в typespecs, а вот здесь можно ознакомиться с ними подробнее.

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

@spec concat(binary(), any()) :: {:ok, binary()} | {:error, any()}
def concat(origin, any), do: origin <> IO.inspect(any)

Библиотека для работы с формулами

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

def notify?(rate) when rate > 2.0, do: true
def notify?(_), do: false

Мы позволяем клиентам добавлять такие проверки динамически. А значит, нам нужен более или менее надежный механизм для проверки условий, добавленных только что.