> Если говорить про область системного ПО, то там часто с UTF-8 дела
> иметь не приходится.Да? Ты читаешь файл конфигурации, в нём может быть много чего, в том числе и utf8-комментарии, или utf8-строчки, между ними затесались имена файлов. Но это собственно не важно: пример с utf8 я приводил, только чтобы пояснить мысль о том, как повышение уровня гарантий может приводить к более быстрому коду.
> Что касается null, то многие функции пишутся с расчетом, что null туда
> не прилетит и никаких проверок не делается в релизном коде. В
> дебажном компилится макросами assert. Где тут потери производительности?
Как где? На практике же. В теории -- да, в теории не должно быть ненужных проверок на null. На практике же эти проверки так или иначе просачиваются в код. На всякий случай. Потому что C не даёт тебе способа доказать, что здесь не случится нулевого указателя. assert тебе тоже ничего не гарантирует: если дебажная сборка не падает на assert'ах, то это доказывает лишь то, что тебе не удалось найти способа уронить её на assert'ах. fuzzing может дать ответ, но он тоже не доказывает, лишь повышает степень уверенности. В rust'е же, если ты создавая ссылки из C'шных указателей в unsafe блоках проверил их на ноль (тут уже в обязательном порядке или с трёхстрочным комментарием поясняющим почему в данном случае проверка не нужна), обработал ситуацию когда указатель NULL, то тогда у тебя не может быть нулевых указателей. Довольно просто всё, и главное легко верифицируемо, даже совершенно посторонним человеком. Такой аудит проведёт и баба Клава, если ей объяснить как в коде найти все unsafe блоки, и на что именно надо смотреть.
> Итераторы в С всегда делались на макросах или на структурах, если нужно.
> Возвращаешь вместо указателя на коллекцию итератор и функцию next.
Это не совсем то. map позволяет указать функцию, которую надо применить к каждому элементу коллекции. У этой функции будут серьёзные проблемы в rust'е, если она попытается иметь mutable доступ к внешней переменной (я не уверен, впрочем, преодолимы ли эти проблемы). То есть, скорее всего она не будет обращаться к внешним переменным и будет чем-то близким к pure function, то есть к функции чьё возвращаемое значение зависит исключительно от значения аргумента, и которая не меняет состояние мира, то есть никаких побочных эффектов нет. А если так, то вызовы этой функции для каждого элемента коллекции можно выполнять в произвольном порядке, хоть параллельно. Это проверяется тривиально в rust'е, и отклонение от этого будет причинять неудобства для программиста. А это значит, что с большей вероятностью код окажется параллелизуемым.
В C это всё можно проделать, но там нет возможности объявить функцию inline, прям в списке аргументов вызова функционала. Поэтому так никто в здравом уме так делать не будет. Проще написать for/while, и отследить глазами, чтобы между последовательными итерациями не было бы зависимости по данным.
