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