1. Кому так себе, кому очень полезная, хоть в проде, хоть на тестовых и дев инстанциях. Разработка не одним продом ограничивается.

Так даёшь свой софт другому разработчику, и не покрыл один ему нужный кейс и там бага. Фикс, хотрелоад и через 2 минуты(включая поиск бага и фикс) другой разработчик уже продолжает работать. Даже вне продакшена - это очень полезно и круто. В другом бы случае неизвестно сколько бы ему пришлось ждать, пока багфикс прийдёт к нему.

2. Всё зависит от того, что твоё веб приложение делает - если это stateless процесс с очень простой задачей, как: прочитать - изменить - записать что-то в базу данных и умереть, то не пригодиться(хотя для тех же соединений в базу данных может пригодиться - но в случае ecto оно уже скрыто за библиотекой), в более сложных же случаях может быть очень полезно.

Привет, Анастасия!

Пожалуйста, реши капчу:

Вычисли: 88+15=...

Осталось попыток: 3
Если не решишь - забаню навеки...
Удачи!

3. GC нужен для soft real time и fault rolerance (для второго ещё и супервизоры даны), если эти два качества не нужны, то может действительно стоит взять язык, который даёт качества, которые тебе нужнее в системе? Т.е. к примеру, чтобы всё работало быстрее, но и было менее отказоустойчивым, чем если писать на Erlang/Elixir. GC per process так же позволяет как можно лучше отделить то, что делает один процесс от другого, что нужно в данном случае и для отказоустойчивости.

Привет, REBECCA!

Пожалуйста, реши капчу:

Вычисли: 99+5=...

Осталось попыток: 3
Если не решишь - забаню навеки...
Удачи!

Да, BEAM в некоторых случаях очень крутая тема, но всё же современные инструменты (та же jvm, go) имеют многие из этих преимуществ + исправляют некоторые недостатки, такие как проблема со строками (решено в Elixir), проблемы с числодробилками, статическая типизация...

А BEAM остаётся всё же довольно нишевым инструментом, хотя конечно же есть задачи, на которые он очень хорошо ложится

Ну, про многие - это перегиб... У меня несколько Java комманд рядом работает, я за ними наблюдал. В особенности, что касается ловли багов и интроспекции - тут разница огромная.

Вот тут да, интроспекция в erlang пока лучше, чем тот инструментарий, который есть для jvm

Привет, Tony!

Пожалуйста, реши капчу:

Вычисли: 25+98=...

Осталось попыток: 3
Если не решишь - забаню навеки...
Удачи!

Вот поэтому если смотреть всё в купе, нет ни одной подобной платформы, дающей даже близко те же самые свойства. Если числодробилка не размазанна по всей логике приложения, вынеси её в другой язык и запускай как ниф или порт. Кстати это местами быстрее того же питона может работать(к примеру: https://github.com/versilov/matrex) да и Beam в целом - хорошо работает как клей. А вот со статической типизацией - тут сейчас ничего особо не поможет... Но если писать тесты и практиковать в этой области best practice-ы вероятность поймать баг, который бы поймала статическая типизация, но не ловят тесты сводится к нулю(в моем опыте). Без тестов конечно рефакторить будет сложнее, чем в случае статической типизации.

Ок, а на сколько важны знания OTP, для того чтобы начать изучать эликсир более глубоко?

Erlang знаю на уровне синтаксиса. Немного ковырял Elixir

Чтобы начать - ни на сколько.

Полезно понять генсервер и дерево супервизоров, но это полезно для всех вообще. В любое время, но надо.

define более глубоко?

имхо важно понимать как устроены процессы и общение между ними, + полезно знать про стандартную библиотеку эрланга

Где доступно про генсервер почитать, ну или где на этом внимание сакцентировано? Примеры может, доклады

Ну и супервизоры. Не знаю, как у Херберта описано, может и его хватит, ещё читаю