Немного писал немного на ней, но потом перешёл на scala

Фу

Чем современный веб отличается от коммутаторов и телефонов? Из базы загрузил - в сокет отдал. Конец...

Почему?

Как можно после Clojure перейти на скала...

и чем тебе эти уши мешают? телеком это офигенно

Наоборот я бы ещё понял

Ладно, мне работы больше )) дело вкуса и хозяйское

Я не знаю как другим, но мне как-то совсем редко приходиться использовать лямбды

Именно через точку вызывать

Ну вот на сколько вообще адекватен подход к распределённым системам, который предлагает эрланг? Нужен ли кому-то сейчас хотрелоад? На сколько полезен подход с супервизорами? GC для каждого процесса... Я понимаю зачем это всё для телекомов, но в вебе это не особо нужно, как по мне

так не нужно пока нагрузки детские. а эрланг предлагает из коробки офигенный подход к многозадачности и GC и иже с ними. И только хот релоад даст тебе аптайм 99.9999999

Эта статистика для AXD301

1) хотрелоад - нужен, фиксить хотя бы маленькие баги хотрелоадом - это просто незабываемые ощущения в любом проекте. Я не хочу работать с языками - это не поддерживающими(не обязательно в продакшене, можно и в тестовых инстанциях). Это очень крутая фича, как и интроспекция виртуальной машины.
2) Подход полезен, тема очень долгая для пояснений.
3) GC на процесс - это следствие того, что хотели достигнуть в Erlang-е(fault tolerance). Анализировать хорошо это или нет - не имеет смысла. Стоит взять задачу и понять, помогает ли её тебе решить Elixir или какой другой язык подойдёт лучше.

Зато пачка докер инстансов за балансером даст тебе аптайм 100%. И пофиг что время жизни одного конкретного приложения может быть полчаса

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

1. Интроспекция - круто. Хотрелоад для прода, как по мне, так себе затея
2. Ну в принципе это может пригодится. Я могу придумать пару кейсов для этого, но всё равно чаще всего можно в вебе без них
3. GC на процесс как раз нужен для мягкого реального времени, но это можно достичь, как я понимаю только за счёт правильный архитектуры, чтобы на один процесс не пересылалось много жирных сообщений. Другое дело, зачем на мягкое реальное время?

Скорее гранулярнее. Если загнётся один  процессик одного пользователя, то тогда допустим загнётся докер контейнер и там было тысячу клиентов, а в Erlang-е падение одного процесса пользователя не трогает остальных. Соответственно временный эффект ошибки до переподнятия процесса внутри Erlang-а или до переподнятия контейнера, в месте с которым это заметят и тысячи других пользователей.