Ну какие радикально новые? Это база, это было в Лиспе 60 лет назад, это было в ML 35 лет назад, это было много где ещё, и теперь есть везде практически. Кроме динозавров вроде Фортрана, кобола и го.

Когда вместо auto evens = xs.filter!even.array; предлагается делать цикл на пять строк это именно каменный век.

Решение на нетипизированных  интерфейсах и рефлексии, которое в 20 раз медленнее чем надо, конечно не годится.

Тут больше jack of all trades, master of none ситуация. Ну то есть условно, если я хочу с машин-лернингом экспериментировать и обучать модели - я естественно возьму питон, матлаб, julia или что-то подобное. Потому что мне условно насрать на производительность, я не хочу думать о памяти и сражаться с системой типов - я хочу решать математическую задачу с помощью компьютера. Если я возьмусь писать ембед или ядро - мне эти ваши исключения и шаблоны не нужны и условно я буду писать на языке малоотличающимся от просто сишки. Если я захочу написать простой бэкэнд для чего-нибудь - ну правда мне проще взять гошку или ту же яву, чем сражаться с буст.асио или новыми коррутинами плюсовыми. Просто у плюсов по мне очень большие проблемы со стратегией развития. Одновременно под эгидой зеро-оверхеда создаются очень сложные и неудобные к использованию штуки и одновременно рядом же в языке лежат фичи с ощутимым оверхедом, но совершенно ненужные. Поэтому условно С++ можно везде использовать, но под мои задачи в основном находились языки на которых решить задачу многократно проще, чем на С++.

Чем иммутабельный foreach отличается от .map кроме визуальной составляющей? (да, я согласен, мне тоже тоже писать arr.map.filter приятнее, но это уже вкусовщина)

ну так это мб ты фичи не осилил, а не они сложные и неудобные?

Statement а не expression (результат не передашь сразу в функцию и не вернёшь), больше кода, больше мест для ошибки. Так то можно и на ассемблере писать.

Понимаю что база. И в каком там году шаблоны в C++ поддержали? И сколько времени потребовалось на починку бага с >> и вообще сколько последствий огребли? И в том же расте передачу в дженерики интов в кач-ве параметров вот буквально позвчера только влили в мастер. Как-то для такой базы опыт внедрения не очень.

С++ тоже не лучший пример для подражания. А инты совать вместо типов это уже нетипично для генериков, это уже более смелые эксперименты.

Ну как нетипично, тип статического массива нужно же мочь запараметризировать

Parametric polymorphism был в ML C 1975 безо всяких проблем со скобками.

шаблонам в ядре место тоже может найтись

Ada, Haskell, Mercury, SML, Miranda, Clean...   Годные языки с генериками уже к 1990 году.

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

Тут правда согласен. И по опыту раста - мочь все растрактовать как выражение правда красивее и удобнее бывает. Но тут логика такая, что цикл в языке нужен - не все выразишь этой функциональщиной. То есть от условного for не отвертеться. А если у тебя уже есть for для циклов, то и все, давайте не разводить зоопарк и жить с 1 не самым оптимальным, но 1 решением. По логике авторов языка - лучше 1 универсальный способ, чем 2 два пересекающихся. В том же расте и питоне очень часто кто как итерирует, кто мапами, кто циклами - в итоге зоопарк. А тут я не думаю - хочу цикл - пишу for. Такое себе, я согалсен, что это больше минус и как только появятся нормальные дженерики - и тут будет зоопарк, но в остальных вещах эта философия языку больше помогает, чем вредит.

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

Пожалуйста, не нужно. Торвальдс запретил С++ в ядре и был прав на 100%. Когда я открываю код стандартной библиотеки раста или гошки или код ядра линуха - я беру и читаю его просто как документацию, как книгу. Когда я открываю код stl и вообще стандартной библиотеки С++ - я не уверен на каком языке он написан. Да, можно сказать, что это я тупой - может быть. Но я лучше поразмышляю почему так вышло, что я не понимаю внутренностей С++, но считаю красивыми внутренности ядра и как такого избежать в будушем.

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

Да я согласен. Но твои примеры больше академические. Гошка при создании больше ориентировалась на промышленный опыт, а не на достижения в теории языков и компиляторов. Изначальная мотивация была создать свой С с плюшками (какой-то ООП, пакетирование, горутины), потому что С++ развивается совсем куда-то не туда. И как С с наворотами вышло именно так как задумывалось. Хотелось бы лично мне большего?  Да конечно. Я очень хочу хаскель с зависмыми типами и с семантикой владения как в расте без гц. И инструментами для деббага функционального кода. Вот тогда заживем. Но пока приходится перекладывать джсоны под хайлоадом, поэтому занимаюсь переписыванием с сишки на гошку - по опыту происходит несложно и в результате код становится пусть чуть, но лучше.

Это да. Немного мешали эти волдеморт-тайпы, потому что везде все с ауто и компилятор сам все знает, а я нет, но в остальном все круто.