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

Вариант сделать свою систему управления зависимостями никуда не делся. Если не прибивать это дело гвоздями централизованно, то разницы между "я тут свой configure написал" и Conan будет никакой)

Рецепты хранятся вместе с кодом, registry можно зеркалировать и поднимать свои

Перегрузок в расте нет.

И слава богу! И пускай никогда не будет! Худшая фича С++! Сколько от неё страданий)

Сделали бы перегрузки допустимыми только для операторов - цены бы им не было.

В расте нет и исключений

И зачем они?

Рефлексии в расте тоже нет

В том виде в котором она есть в С++ - нет. Но процедурные макросы ничем не хуже, а даже лучше.

Ну и С++26 ещё не приняли, в значит и в плюсах её тоже нет.

И я пока не вижу зачем эти 5% продолжают писать на asm)

Но сколько таких мест? И сколько надо программистов для них? И не справится ли LLM с этой задачей?)

Вопросы для меня не имеющие очевидного ответа, я просто не живу в мире настолько низкоуровневого программирования и не знаю никого, кто бы жил

Я помнится какой-то температурный датчик программировал, у него даже ассемблера не было, а компилятор на Си был) Компилировал он сразу в unsigned char массив, который ты хоть азбукой морзе загоняй по SPI внутрь этого контроллера)

asm более или менее оправдан в крипте, да и то, на нем там не пишут, а прячут за кодогенерацией и/или макросами.

Да и вообще, всё что меньше 1/10 секунды, в операционных системах общего назначения малопредсказуемо.

Это не так, если ядра изолировать

Только в отличие от ranges, лямбду можно прикопать в std::function на всякий случай, если хочется. Как прикопать шаблонное месиво, которое плодят ranges - я не знаю)