Ну вот тут не соглашусь, пакетная организация кода чего только стоит в D, а так же не нужно разделять на .cpp и .h исходники. Да и вообще С++ слишком переусложнен. Вот пример кода с хабра:
int& (*fpi)(int*) = [](auto* a) -> auto& { return *a; }; // OK
Все понятно?

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

Именно так: я не нашел ответа на "зачем мне нужен D? для каких задач D будет эффективен/полезен?", поэтому дальше "hello, world!" и нескольких простых оценочных задач интереса не возникло.

Основное впечатление: в язык надергано "специальных случаев" на вкус авторов. Какую целевую область они при этом хотят прикрыть (и какой ценой) --- осталось непонятным. (Точнее, осталось понятным, что авторы языка этим вопросом совсем не заморачивались).

в общем-то, это и была оригинальная идея. повыкидывать legacy и сделать нечто вроде «c++ done right». а потом туда пришёл Александреску и добавил: «and templates done right».

С таким успехом и ассемблер - примитивный аналог Си. :)
Разработчикам не нужны "аналоги", "копии", "обходные пути" - им нужен ПРЯМОЙ инструмент для выражения своих мыслей. Ну и надёжный, конечно - что Ди и сделал как замена таймбомбовому Цэ-пи-пи.

Линуксу давно уже нужен нормальный язык, позволяющий хотя бы в 21 веке забыть кошмарный сон "buffer overflow" (а количество этих потенциальных уязвимостей растёт десятикратно с каждой новой перделкой/библиотекой, потому что пишется всё головотяпами-энтузиастами).

с первого взгляда эта фича кажется бессмысленной, но если узнать, что в ди во время компиляции можно исполнять код на ди (ограничение — нет глобальных переменных; но на функциональщине можно много всего сделать; например, функция toHash(), вычисляющая SuperFastHash, работает как во время компиляции, так и во время исполнения), то mixin'ы сразу становятся намного более интересными. потому что строки для них можно генерировать довольно сложным ди-кодом.

например, парзить дишным кодом во время компиляции некие файлы с диска и на их основе генерировать дишный код (привет, шаблоны страниц в vide.d).

Этот ваш Дэ задумывался как c++ done right, но в итоге смачно лососнул у c++. О чем говорит текущая его популярность, а вернее его отсутствие. Видать не совсем уж и done right

«окончательная стабильность» — это «dead as a doornail».

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

чуть активней ломают std, но и то не так быстро, чтобы это сильно напрягало. всегда есть время на починку старого кода (компилятор заругается на deprecation), плюс можно привинтить слой совместимости обычно, если очень уж чинить не хочется (или просто взять старый модуль). на практике — ломается не так много, и в основном то, что касается всяких околосистемных вещей — типа запуска процессов, обёрток над clock_gettime() и ты пы.

ходят разговоры про написание «автомигратора», как в Go, но говорят многие, а делать никому не хочется. в принципе, парзер D на D есть, и продвинутый линтер на его основе тоже есть — так что писать не то, чтобы совсем с нуля надо. но пока — благодаря малому количеству «ломающих изменений» — всем проще починить свой код руками и не заморачиваться написанием (и, что намного важнее — дальнейшей поддержкой) такой тулзовины.

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