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

Сам по себе язык едва ли можно назвать юзабельным. На первый взгляд всё просто и логично, но при попытке написать программу крупнее хеллоуворлда, замечаешь, что события, предназначенные для одних мест прилетают в другие, параллельно выполняющиеся тесты ломают друг друга, и отладка становится почти невозможной. Всё меняется, если использовать OTP...

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

В виртуальной машине Beam всё выполняется параллельно, и ближайший аналог ООП-объекта в Erlang называется процессом — процессом виртуальной машины Beam. Но это не объект как в Java или C++. Это рекурсивная функция (хвостовая рекурсия), которая может останавливаться, ожидая сообщений, и как правило так и делает каждую итерацию. Тогда состояние процесса — в списке аргументов этой функции.

Ближайший аналог Java-интерфейса — поведение (behaviour).

Pid в контексте Эрланга также относится к процессам внутри Beam.

Вытесняющая многозадачность процессов в Erlang достигается планировщиком задач, как у операционной системы. И он даже более агрессивен в равномерном распределении вычислительных ресурсов между процессами, чем в Linux или Windows. Его задача №1 — предотвратить массовый отказ в обслуживании из-за зависания одного процесса.

Эту фичу часто понимают неправильно. Допустим, вы пишите программу на мэйнстримном языке, и вам нужно сильно параллелить выполнение. Первый вариант, как можно это сделать — создать много процессов операционной системы, но это займёт очень много памяти. Второй вариант — вручную или в рамках фичи платформы сделать небольшой пул тредов ОС, которые будут переключаться между задачами по мере необходимости. Как правило, такие решения реализуют кооперативную многозадачность: пока зелёный процесс или корутина не отпустят выполнение, процесс ОС останется заблокированным. Операционные системы же почти все сами переключают процессы, что не даёт ни одной программе повесить всю систему. Так и поступает Beam.

Итак, поскольку процессы — это рекурсивные функции, которые ждут сообщения и по-разному реагируют на разные сообщения, в OTP они разделены на два класса — state-машины (gen_statem), рабочие лошадки любого проекта, меняющие своё состояние и в первую очередь воспринимающие внешние вызовы как спусковой механизм изменения состояния, и серверы (gen_server), воспринимающие сообщения как запросы к некоторому ресурсу. Над ними стоят супервизоры, единственная задача которых — выключить и включить.