> Я боюсь, что 99% ваших программ не нагружают GC и до половины.

Половина -- это в каком смысле? Это когда 50% доставшихся ей тактов процессора программа тратит на сборку мусора? Да элементарно, вот смотри, я сейчас пишу программу, чтобы натягивать звуковую дорожку с одного видеофайла на другой, при необходимости растягивая эту дорожку или сжимая, потому что один из файлов имеет покорёженную ось времени. Для этого я декодирую первый файл, перебирая кадры, находя там ключевые, потом второй файл. Потом сопоставляю две последовательности кадров, строю отображение оси времени второго файла на ось времени первого, ну и дальше режу звуковую дорожку на кусочки и каждый кусочек немного растягиваю или сжимаю. Я не знаю, сработает это или нет, но это не суть, в данном случае.

Так вот, давай представим себе, что я декодируя видеофайл выделяю под каждый новый кадр новый кусок памяти. Некоторые куски я сохраняю, но большинство я выкидываю обратно в кучу. Понятно, что можно было бы не выкидывать, а использовать повторно, но, во-первых, задача-то в том, чтобы убить программу сборщиком мусора, а не реализовать максимально эффективно, а во-вторых, при ручном вызове free на ненужные кадры, это будет иметь несущественное влияние на производительность, на фоне декодирования кадров и сравнения последовательных кадров на предмет различий.
В случае же GC, доступное место в куче будет уходить в ноль постоянно. И сборщик мусора будет постоянно искать мусор. И это может быть не очень страшно было бы с generational сборщиком мусора, такой сборщик мусора по-крайней мере гарантировал бы мне постоянство задержек, как бы много кадров я не обработал. Но консервативный будет при каждом запуске сканировать каждый мой сохранённый кадр, ища в rgb данных указатели. Как думаешь, сколько мне надо набрать кадров в оперативке, чтобы программа 50% времени проводила бы за сборкой мусора?

> Зачем тогда гнать эту пургу про производительность?? Сначала напишите что-то тяжёлое,
> потом уже жалуйтесь на *реальную* проблему.

Речь не о "реальной" проблеме, а о причинах фейла D. Разные проекты и особенно начинания часто фейлятся не из-за "реальных" проблем, а из-за какой-нибудь совершеннейшей фигни. Скажем сам факт того, что в D есть сборщик мусора, является очень серьёзной преградой для перетягивания C и C++ программистов в D. И не потому, что сборщик мусора не позволит этим программистам решать их задачи, а потому что у них голова не приемлет идеи. "Реальная" ли это причина? Я не знаю как ты отвечаешь на этот вопрос, я отвечаю положительно: я уверен, что она реально повлияла на успехи D в привлечении программистов.

Как гугл со своим Go боролся с этой проблемой? Он лил программистам в уши маркетингового буллшита: https://blog.golang.org/go15gc
Но начал он с того, что действительно реализовал конкурентный, трёхцветный, mark'n'sweep для Go. Тоже позорный gc, но всё ж не консервативный, и при этом они реально добились снижения задержки. Но суть в том, что Google сначала реализовал, а потом включил генераторы буллшита. D не льёт в уши буллшита и не реализовывает хороший сборщик мусора. Безнадёжно.