я использую edts (кажется это реинкарнация distel), но это скорее вынужденная мера (у нас очень большой проект). работает довольно отвратно =(

Офигеть читабельность:

https://github.com/erlang/otp/blob/master/erts/preloaded/src/erlang.erl#L3211

Вот это тоже понравилось:
of
 Bool when Bool == true; Bool == false -> Bool;

вау! прикольно!
оказывается, можно так писать —

case case ....
end of ....
end

case case ....
end of ....
end

А в чем противоречие? Почему так не должно быть можно?

не встречал такого, и не пробовал
в разрыве шаблона)))

case case ....
end of ....
end

Тогда можно и:
case case case case ...

занятно)) тут можно булькнуть иначе —

Bool when is_boolean(Bool) -> Bool;

Вообще, тут головняк в erlang:error(...). Приходится try/catch лепить

Вот проблема: в mpegts decoder как ни верти, в топе setelement и keystore.

Потоки данных порезаны на куски по 184 байта и раскиданы, перемешаны.

Надо их обратно склеить.

Плата за иммутабельность :(

Мапы не помогут?

Мапы сами по себе не оч дешёвый вариант. Уникальность ключа не бесплатна. Хотя, тут специфика нужна, чтобы Файн тюнинг рекомендации давать

Я думаю, что в Erlang-е должна быть unsafe(можно даже куски кода, работающие с мутабельными данными помечать unsafe, как в Rust-е для unsafe кода) мутабельная структура данных для таких случаев, которая сохраняет структуру в памяти один в один, как в неё пишешь, т.е. чтобы можно было при передачи её в C код - как из массива читать и заполнять и прямо в Erlang-е изменять in place. Чтобы там, где нужно переключаться на мутабельность - не используя для этого Rust/C/подставить свой язык. Это открывает может быть и немного опасный путь, но даёт очень сильный инструмент в опытные руки на те случаи, когда оная действительно очень нужна.

Что думаете по этому поводу?

Не понятно

а зачем тогда эрланг?
пишите сразу на расте, плюсах etc...

Было бы хорошо, если была возможность иметь мутабельную структуру данных в Erlang-е и прямо в Erlang-e иметь возможность её изменять, т.е. мутировать.

это уже не эрланг будет

Можно таеоеделать нифами если хочется

Можно, но у этого подхода есть два минуса:
1) нужно писать на другом языке
2) постоянное переключение контекста между beam и не beam съедает свои ресурсы.

Мутабельность тоже думаю будет недешева