В ИТ есть странная форма «информационной инерции»: когда фраза однажды удачно легла на реальность, стала цитатой, превратилась в маркер «своего» - и дальше продолжила жить сама по себе. Реальность уехала, практики сменились, инструменты стали другими, экономика разработки перевернулась, а штамп формулировки остался. И особенно охотно её повторяют те, кому нужно писать быстро и убедительно, но нет времени (или компетенции) разбирать в технических деталях.
И проблема не в том, что старые тезисы изначально были бессмысленными. Проблема в том, что их продолжают подавать как вечные законы природы - без даты, без контекста и без поправок на то, что индустрия в корне изменилась.
Например, фразы про “серебряную пулю” и "небезопасный С++ ", которые звучат почти в каждом популярном тексте о разработке и безопасности, и оба часто переворачиваются так, что становятся откровенной неправдой.
«Серебряной пули не существует»: мем остался, а смысл переврали
Тезис Брукса не был утверждением, что «кратных улучшений не бывает». Он был направлен против ожидания универсального чуда, которое даст порядок прироста продуктивности «везде и сразу» - просто за счёт использования новой технологии. Именно это уточнение в пересказах обычно исчезает и остается только лозунг: «серебряной пули нет». Очень короткая и эмоционально удобная фраза, которую затем применяют как общий тормоз: не ищите возможностей, не рассчитывайте на технологические скачки, всё равно «магии не бывает».
Однако «серебряная пуля» давно существует, используется и выглядит прозаично: бесплатно (или почти бесплатно) взять готовые компоненты - библиотеки, фреймворки, инфраструктурные сервисы, стандартизованные протоколы и реализации - и тем самым не «ускорить написание кода», но многократно уменьшить общий объем работы проекта, и не выполнять повторно работу, которую рынок уже выполнил и упаковал в повторно используемую форму. Это реально экономит труд кратно - иногда на порядок и даже несколько порядков, о чем даже и не мечталось автору исходного выражения.
Это и есть реальная «серебряная пуля», о которой Брукс в более поздних комментариях и переизданиях писал куда более примирительно: универсального чуда нет, но компонентность, повторное использование кода и зрелые платформы способны давать огромные выигрыши там, где раньше люди действительно многократно переписывали одно и то же много раз, тратя на то время и ресурсы.
«C++ - самый небезопасный язык»: подмена предмета разговора
Утверждение «C++ небезопасен» часто произносится как оценка языка вообще, без уточнения модели угроз, характера кода и процесса разработки. В таком виде оно почти бесполезно: безопасность - это свойство системы и используемых практик, а не ярлык на названии языка.
Технически корректная отправная точка другая: C++ не является memory-safe по умолчанию и допускает неопределённое поведение. Следовательно, при отсутствии инструментального контроля кода, вероятность критических дефектов выше, чем в языках, где значительная часть ошибок управления памятью конструктивно или семантически исключена.
Но из этого не следует, что С++ «самый небезопасный». Во-первых, сравнение «самый» не имеет смысла без определений: какие классы уязвимостей рассматриваются, какие ограничения на среду, какой тип проекта (встроенные системы, high-performance backend, UI, криптография, драйверы), какой уровень доверия к входным данным, какие требования к отказоустойчивости. Во-вторых, C++ предоставляет достаточный набор механизмов, чтобы заметно сократить типовые риски - при условии, что команда пишет код и организовала собственную работу.
Тут приходит на ум сравнение с «буридановыми мышами», когда возникает паралич выбора: одновременно хочется иметь и «свободу» и «минимальные изменения» и «нулевую стоимость» и «скорость разработки» и «отсутствие уязвимостей». Но это часто взаимоисключающие требования.
А когда в результате не выбирается ни строгий режим разработки на C++ (с ограничениями и проверками), ни миграция туда, где безопасность обеспечивается конструктивно (Ada, Rust), вот тогда и остаётся третье: продолжать кушать кактус писать код привычным образом, регулярно получать ошибки управления памятью или UB, а затем объявлять проблемы безопасности свойством инструмента и продолжать использовать небезопасные практики и жаловаться на язык, как на первопричину всех проблем.
Поэтому проблема с “небезопасным С++” не в том, что он не даёт безопасно писать код, а в том, что команда не хочет платить за безопасность тем, чем она в C++ оплачивается: дисциплиной, ограничениями и автоматизированными проверками…
Когда у фразы истёк срок действия или отсутствует контекст
Устоявшиеся мнения в ИТ часто превращаются в «вечные истины» только потому, что их удобно повторять. Но технический мир не обязан подстраиваться под цитаты тридцатилетней давности.
«Серебряные пули» в виде LLM, повторного использования экосистем и сервисов существуют и они реально уменьшают сложность и дают кратные выигрыши по объему работ по сравнению с разработкой кода многолетней давности.
Так и наличие ошибок в коде C++ не превращается его в «самый небезопасный язык». Да, C++ не гарантирует безопасность автоматически. Она требует дисциплины и инструментального контроля и С++ может быть достаточно безопасным для множества системных задач, особенно там, где важны контроль, производительность, интеграция и предсказуемость.
Конечно проще про C++ сказать «язык плохой», чем признать: проблема часто в том, что «буридановы мыши» не выбирают ни безопасность как цель, ни процесс как средство - они выбирают кактус привычки и затем делают из своей боли мировоззрение.
