На практике от статической типизации лишь проблемы с ручным привидением

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

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

> Кто может объяснить, зачем в языке с неизменяемыми переменными нужны статические типы данных? Ловить ошибки. И теоретически это может доползти до оптимизации в BEAM

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

> В языках с системами типов их тысячи, и для каждого типа свои операции, и в каждой операции свои подводные камни, которые нужно помнить Так и в Erlang и Elixir есть по пачке функций для каждого типа. То о чём ты говоришь, это не свойство статической или динамической типизации, а скорее свойство слабой или сильной. То есть это в JavaScript ты плюсиком и строки склеиваешь и числа складываешь. Как это хоть что-то упрощает?

Стикер

> знать что делает что нужно именно программисту Так у тебя и в Erlang/Elixir нужно знать что что делает. Если ты в статически-типизированном языке вызовешь функцию/оператор/метод над переменной того типа, который с этой функцией не работает, статически типизированный язык в компайле упадёт, а динтипизированный в рантайме. Конечно, иногда может быть каламбур типов, и у тебя компилятор схавает >> и подвинет байты вместо вывода с cout, но в происходит несравнимо реже, чем вызов maps:get над каким-нибудь {ok, Result} в Erlang

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

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

Причём тут джун или не джун? Мне кажется, что конечно количество ошибок с опытом уменьшается, но все мы регулярно баги выдаём, причём довольно часто очень тупые типа null check (aka none check в Erlang или nil check в Elixir). Статически типизированный компилятор именно такие ошибки и ловит (и ещё много других)

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

Это скорее уже к дизайну языка вопросы. Есть статически-типизированные языки, где всё это приводить не нужно, например Java, Kotlin

Что в Kotlin, что в Nim, не говоря уж про Go, статика надоедает, подходит лишь для самого нижнего уровня, которым сейчас являются микроконтроллеры, но в нормальных языках её меньше, где есть автоматическое приведение типов, и более-менее свободное использование числовых типов. А какие есть проблемы с динамическими типами данных в языке с неизменяемыми переменными? Я заметил лишь проблемы с тем, что в Erlang повторное использование переменной вызывает ошибку, так как уже используется сопоставление, а не присвоение, в Elixir это элегантно исправили.

> А какие есть проблемы с динамическими типами данных в языке с неизменяемыми переменными? Такие же как и везде. Можно написать и написать код, который никогда не сработает нормально, и никто тебе об этом никогда ничего не скажет. Например, где-нибудь ошибиться в case-ах и вернуть просто Result вместо {ok, Result}. А потом поймать это в проде, а не во время компиляции > Elixir это элегантно исправили. Я бы не сказал что исправили. Это скорее дело вкуса. Эрлангистам вон просто нравится писать State1, State2, State3, State4, State5 и т.д.