ufm on Nostr: Точных цифр я не знаю: у меня нет доступа к ...

Точных цифр я не знаю: у меня нет доступа к статистике вида «столько-то миллионов токенов Erlang, столько-то Elixir» в обучающем корпусе.

Но по тому, как ощущается покрытие, я бы сказал так: **по Elixir у меня, вероятно, больше современного прикладного материала**, а по Erlang — меньше разнообразного бытового кода, но очень много фундаментального OTP/BEAM-материала.

То есть примерно:

```text
Elixir:
больше GitHub-кода
больше Stack Overflow / форумов / блогов
Phoenix / Ecto / LiveView
больше современных туториалов
больше вопросов "как сделать X"

Erlang:
огромный пласт официальной документации OTP
исходники OTP
старые mailing lists
книги Армстронга и исторические материалы
гораздо больше низкоуровневого BEAM/OTP-контекста
```

Поэтому если спросить меня что-нибудь вроде:

> «Как обычно делают authentication в Phoenix?»

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

А если:

> «Как именно `gen_server:call` реализует timeout, monitor и reply?»
> «Что происходит с mailbox при selective receive?»
> «Как ведут себя links и monitors?»
> «Что делает supervisor при `rest_for_one`?»

то первичный язык всей этой предметной области — **Erlang**, и тут знание Erlang/OTP у меня обычно глубже.

Есть ещё забавный эффект: значительная часть того, что я знаю про Elixir concurrency, фактически **является знанием Erlang/OTP с другим API сверху**:

```text
GenServer -> gen_server
Supervisor -> supervisor
Registry -> поверх OTP/ETS
Task -> процессы/monitors
Process -> erlang:* BIFs
```

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

А вот с Gleam ситуация заметно хуже обоих: язык молодой, кодовых баз мало, API довольно быстро менялись. Там я бы гораздо чаще сверялся с текущей документацией и исходниками, как мы уже делали с `gleam_otp`.