N>Про перекодировку я ни слова вообще-то не сказал, это уже ваши... мнээээ... догадки я говорил про посылку.

Вы прямо заявили: "при неустранимой динамической типизации Erlang и очень слабой JIT компиляции (где она вообще есть) Erlang не может быть быстрым."

Для типичных коммуникационных задач Эрланг более чем быстр. В отличие от number crunching и подобных задач, включая ту самую перекодировку.

N>Но при наличии рядом уже заметного количества достойных конкурентов, которые способны обеспечить то же самое по результату, при этом минимально требуя бутербродизации — чем тут Erlang будет сильно лучше?

А вот тем самым, что вы и описали ниже:

N>Ну да, вместо OTP с супервизорами и рестартами — будет какой-то закат солнца вручную, пригодный для местных условий. И обмен сообщениями будет перенесен на какой-то свой движок, который может работать даже поверх мьютексов и условных переменных. А где-то его и не будут использовать, если удобнее без него.

^^^ иными словами, "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."
Вот ровно так и есть. До того как я начал пользоваться Эрлангом, у меня тоже были закаты солнца вручную, "свои движки" и подобное. Да, оно работало побыстрее, чем аналогичный софт на Эрланге (просто в силу близости к железу), но багов, увы, там было немало.

Короче говоря, можно переизобрести этот велосипед (эрланг) еще 10 раз. Например, akka streams есть не что иное как. И Orleans тоже. И go, и вообще практически весь современный concurrency-oriented софт.
Просто чтобы это понять, нужно потратить очень много времени на изучение сложившейся ситуации. На то, чтобы научиться пользоваться всеми этими инструментами, и иметь возможность их сравнить. У меня такая возможность была. Надо понимать, что Erlang — очень, очень-очень взрослый язык. Даже, пожалуй, старый — поэтому мы и обновляем его (не только виртуальную машину, но и язык тоже). И вот эта самая взрослость — maturity — и позволяет увидеть простую истину: ничто не ново под луной. Новомодним технологиями еще только предстоит тот путь, который Эрланг уже прошел.

N>И обратите внимание, что с массовым переходом на rebar/mad (а кто сейчас пакует без них?) успешно похерена самая главная вкусность — обновление на ходу, и всем пофиг — задача перенесена выше, на уровень контейнеров, докеры-шмокеры-куберы.

Смешались в кучу кони, люди... чем rebar-то помешал? Как раз он-то прекрасно подходит для генерации релизов, и relup-ов. Я как-то даже урок для своих делал, показывающий, как оно работает.
Докеры-шмокеры, это, конечно, прекрасно, но не потому, что у Эрланга что-то не так, а потому, что программистов, которые умеют разрабатывать софт, очень-очень мало, а обезьян много. И обезьянам проще дать контейнеры, чем пытаться из научить понимать фундаментальные принципы.


N>Когда я работал в Massive Solutions, мы и с ESL общались плотно, и с Вирдингом я лично разговаривал. Не думаю, что он меня помнит, но ESL должны помнить про попытки старта совместных проектов.
N>Основной наш проект был роскошным, но в результате я не хочу на Erlang больше ничего делать.

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

Реальная проблема у Эрланга только одна. Он не для обезьян. Надо понимать, что делаешь, если хочешь написать что-то серьезное. Или, если говорить в терминах менеджмента, "there are staffing issues". Как пример, десяток инженеров могут сделать WhatsApp — потому что это сильные инженеры. Но если брать среднестатистическое, то... даже у сотни не получится. Проще на PHP.