да, наверное, противник. это цена, которую я не очень понимаю, за что имеет смысл платить.

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

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

Я наверное примерно понимаю о чем ты

Интересно откуда у этого различия растут ноги? Мне, вот, лично когда проект становится больше 3-4 файлов (<1000 строк) уже просто не комфортно без типов, я не могу нормально думать без них. Мне нужно понимать, с какими сущностями работают функции и как они выглядят. Без типов лично я забываю это все моментально и в результате каждый раз приходится рыться по коду и понимать ак выглядит какой-либо тип. И выходит намного проще эти типы явно описывать.
Может у меня на столько плохая память, что мне они так нужны.

>опросы "что вывалится в json" можно решать гораздо менее радикальными способами

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

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

Алгебраические типы данных - это, имхо, просто must have в современном яп. Без них писать - это боль.

по мне так erlang предметноориентированный язык. натягивать на него теорию программирования пустое

какой профит от типов будет ? контроль ошибок во время компиляции + усложнение обобщенного кода. можно сделать на всё рекорды и попробовать как оно

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

Пример: typescript - компилирует javascript и находит в нём уже ошибки без указания типов.

И тогда профит - нахождение ошибок без downside-ов, а уже прописывать типы для ещё больших гарантий - дело каждой комманды, каждого разработчика.

для генерации  edoc хорошо..

Можно возвращать из мейлбокса экзистенциональный тип: exists t : type, x : t

ADT это всего лишь крошечные определения. Этим подходом можно пользоваться практически в любом япе

С принудительной статической типизацией ерланг может превратиться в +1 энерпрайзно майнстримное г . Везде заборы из типов будут куда ни глянь.
Ну и смысл будет на нем писать, если писанины больше станет изза определения и контроля типов.
Тогда уж лучше будет на Rust переползать или на старый добрый C/C++.

В рабочий день программист по-нормальному думает три часа, а пишет код 15 минут. Щас бы увеличение писанины считать за минус, если пишешь по 400 слов в минуту на клавиатуре, а эта писанина спасает тебя от идиотских багов в джире и делает код не write-only

Если впадлу думать больше, то так и пишите, это тоже валидный аргумент

Полунадуманный, полуподсмотренный вариант может выглядеть так.

0) Не тащим типы в рантайм, дженерики стираются. Для обратной совместимости байткода
1) Тип Pid имеет тайп конструктор. Для начала пусть принимает тип принимаемого сообщения. Pid[MyMessage]
2) Об ADT говорили выше. Простите за эликсир, возьму оттуда структурки, сделаю тип сумму и навешу тайп алиас

type MyMessage = MyStruct1 | MyStruct2 | MyStruct3

3) spawn расширяется на тип принимаемого сообщения. spawn(MyMessage, fn -> end)
4) С этого момента в компайлтайме невозможно отправить актору сообщение не из MyMessage
5) В скомпилированном виде не поменялось ничего, Pid[MyMessage] стал обычным pid
6) Добавление нового вида сообщения в общий тип роняет компиляцию, если не распаттернматчил его в кейсе. Потому что становится возможным и очень просто посчитать все возможные типы

ну да, придется думать,
а не копипастить половину
проекта из предыдущих,
потому как иначе сейчас
в Erlang никак.
Композиции, интерфейсы,
эффекты
разные выделять, писать
разработчикам, что пора
уже нормальный HKT
заиметь, ADT мало.