Конечно же, под памятью мы понимаем любые ресурсы, каналы там, сокеты, и всё-всё остальное.
По определению, никакой язык не в состоянии гарантировать ничего что выходит за рамки среды, которую он контролирует. Race может быть внешним, от языка не зависящим, он может быть gracefully processed (извините, не могу найти русский эквивалент), или может привести к проблемам. Собственно, про это явно говорится в документации к Rust.
Видимо, популярные ОС, приложения под них, браузеры, виртуальные машины и все остальное пишут неопытные.
Да, неопытные — большей частью. Тот факт что им удается сделать что-то работающим, нисколько не исключает тот факт что их способ — не самый оптимальный и не свободен от ошибок.
Это не значит что ничего не нужно делать, если не делать это хорошо — но факт остается фактом.
Если оно уменьшает количество багов хотя бы в 2 раза, то это уже хороший такой толчок. А для этого есть все предпосылки.
Неважно, сколько яда попадёт в ваш организм, если это смертельная доза. Мне, как потребителю, неважно, что программисты пофиксили 99% багов, если из за 1% отказали тормоза и я въехал в бетонную стену. Радуйтесь, что в большинстве случаев это не тормоза.
И у разработчика остается только либо исправить ошибку, либо написать unsafe, отстрелить ногу, и получить возврат кода на review, потому как проверить тыщи строк PR'а пытливым взглядом сильно труднее, чем зацепиться взглядом за unsafe, и попробовать детально проанализировать чем он занимается.
В этом и заключается проблема современных разработчиков.
Более чем 10 лет я писал write-only код, который вылизывался перед продакшн, потом работал более чем эти самые 10 лет без единой проблемы (и это был не Rust), и единственная поддержка в которой он нуждался — это хорошая документация. Увы, эти времена прошли, за последние 20 лет я не встретил (лично) никого кто был бы на такое способен. Печаль.
По микро движениям можно изменение пульса измерять, учащение дыхания.
По пульсу и дыханию масса астматиков стала бы лжецами.
При попытке соврать человек пытается блокировать или изменить мимику, наверно можно по видео детектировать микродвижение мышц лица.
Профессиональные лжецы и жулики делают это естественно. Главное — верить в то что говоришь, хотя бы временно. Это тупиковая ветвь.
Человек проговаривает мысль про себя, просто сигнал очень слабый.
Далеко не каждый человек. Профессиональный лжец не задумается вообще, он выдаст мысль без задержки, и ему поверят. Даже ИИ.
Если человек верит в то что говорит, даже временно (пока говорит), отличить это от реальности невозможно. Все, кто утверждает обратное, просто жулики или дилетанты.
В конце концов, если бы это было возможно, то это бы уже давено применялось. Но практика показывает, что даже если целая банда психологов называет человека лжецом, это вовсе не факт. И наоборот тоже, соответственно.
Ещё раз повторюсь — Rust гарантирует только отсутсвие race, связанных с памятью. Точка. Все остальные вы ничем не грепнете, потому что к unsafe они не имеют отношения.
Хотя, в любом большом проекте с сотнями тысяч строк кода, не зная архитектуры приложения, не зная намерений разработчиков, не зная самого кода (внешний review) греп вам очень мало поможет.
Что касается других языков (любых) — нужно изначально писать код, который к ним не может привести. Пряморукий и опытный разработчик это сделает легко даже на ассемблере, причём на автомате, ему не нужна помощь компилятора.
Я не спорю что языки типа Rust снижают количество очевидных ошибок, но всё равно, большей частью речь только об ошибках связанных с обращением к памятью, в редких случаях других очевидных ляпах (типа присваивание вместо сравнения как в C, хотя это может быть и намеренно) — но это не решает проблему с багами в целом, это лишь уменьшит их количество (ненамного — C/C++ и прочие «небезопасные» языки и так мало где используются уже).
Если даже «прям щаз» всё что написано на C/C++ перепишут на Rust, это не сократит количество багов и уязвимостей даже на половину — по крайней мере, до тех пор пока разработчики не станут намного более квалифицированными.
Непонятное какое-то сравнение. У хаскелля тоже есть llvm бэкенд, значит ли это, что они будут по производительности равны (если мы уберем проверки индексов)?
Одинаковые алгоритмы с одинаковыми структурами данных — да, будут равны. Например, простая функция которая возвращает сумму элементов целочисленного массива — написанная на Rust, C, C++ и хаскеле, пропущенная через LLVM — выдаст (с вероятностью 99,9%) одинаковый код. Если мы углубимся в объекты и тонкости их реализации с таблицами методов и прочими безобразиями — тут уже, скорее всего, будут отличия поболее.
Большинство бытовой и подобной техники — это всякие жабы со всеми вытекающими. Миллиард устройств не на ровном месте взялся.
Я вообще-то говорил не о простой «бытовой» технике, не зря сказал про автомобили — там практически нет багов в продакшн именно потому что производитель очень материально отвечает за их последствия. Насчёт жабы там сильно сомневаюсь, мощности и память не те. Впрочем, думаю, если найдут баг в микроволновке, которая взорвется или загорится из-за перегрузки, если в определенной последовательнсти нажать какие-то кнопки — то призводитель тоже ответит по самое не могу. А если розетка управляемая Алексой не включится — то да, никто не будет отвечать, хотя хз какие там будут последствия.
То есть язык должен был максимально неудобным, чтобы программист всегда был «в тонусе»? :)
Я где-то сказал «неудобным»? Он просто не должен вставать у меня на пути, если я явно этого не хочу. Моя программа — я царь горы. Это инструмент. Если мне непосчастливится работать в компании где это обязательно (стреляющий за ляпы компилятор) — ок, другое дело. Но пока у меня есть выбор — я хочу им пользоваться.
Верьте или нет, но после первых 5 лет написания проектов на C, я научился не делать ошибок связанных с работой с памятью, валидация всего на входе, выходе и даже между ними у меня уже в крови, даже в наскоро написанных программах — зная о чём нужно думать, их легко избегать, особенно когда отладчик использовать невозможно и приходится всё держать в голове (да, в те далекие времена отладчики были роскошью, впрочем, как и наличие какого-либо компилятора C).
И чем мне тут помог бы Rust? Вы конечно скажете что я могу устать, опечататься etc — да, когда-нибудь это начнёт случаться. Но я глубоко уверен, что если человек начинает настолько уставать или становится невнимательным, что делает ошибки в коде (которые не замечает после первого перечитывания на свежую голову) — ему пора менять род деятельности, на тот где он не сможет делать ошибок, по крайней мере таких ошибок которые не сможет исправить до выкатывания продукции в прод.
Глупо обвинять в том, что естественно.
Я не обвиняю, я указываю на источник проблемы. Как это ни прискорбно, но это из серии «нет человека — нет проблем». Поэтому идеальное решение — устранить из цепочки человека. Чуть менее идеальное — заставить его ошибаться почти никогда, или исключительно редко. Получается ведь у тех кто бомбы обезвреживает, почему не получится у программистов?
Никто не будет работать по таким правилам вообще. Если вы введете расстрел за баги — наследующий день у вас будет куча новых шоферов и грузчиков, и ни одного программиста.
Давайте всё же не будем утрировать — я не такие драконовские меры предлагаю. А насчёт «никто не будет» — снова напомню про производителей автомобилей и прочей техники, где ответственность за баги весьма чувствительна (станки с ЧПУ и прочие промышленные роботы, как пример) — работают же, причём почти без багов. По крайней мере без таких которые явно ощутимы или даже хотя бы заметны. Причём, заметьте, автомобили при этом стоят вовсе не миллионы — эти микроконтроллеры и прочие embedded есть даже в дешевых авто.
Не хотите отвечать за содеянное — не берите деньги, а если уж берёте — то отрабатывайте и отвечайте за косяки. Я лично готов, а вы?
Там доказано, что в случае если мы будем использовать сферического коня в вакууме, то race не будет. Конечно, я утрирую, но они делают массу предположений о среде, библиотеках, etc. — а вы пишете «спасает от всех рейс кондишнов» — в то время как в труде говорится о конкретных, а не всех.
Грубо говоря, вы не правы. Пусть у нас есть безопасный код, разбавьте код unsafe {NOP}, он будет таким же безопасным.
Мне казалось очевидным, что речь шла не про unsafe {NOP}. Речь шла о том что при желании, незнании (или неправильном знании, или малом опыте) race очень легко можно устроить, язык этого не предотвратит сам по себе.
Вот если бы ни при каких условиях, независимо от того как и какой пишется код, race были бы невозможны в принципе — тогда да, я бы с вами согласился. Но это, увы, не так.
Или вот статья — как думаете, во сколько раз наивный написанный в лоб раст медленнее оптимизированных плюсов?
Код коду рознь, а если у компиляторов один бэкэнд (LLVM) — то всё опять таки упрётся в дополнительные телодвижения (типа проверки индексов), которые оптимизацией невозможно убрать в ряде случаев, просто в принципе невозможно (см. мой пример выше).
Сколько роликов про удаленный взлом каких-нибудь Тесл не перечислить.
Пример не совсем корректен — Тесла это сырой продукт, да и если докажут что авария случилась из-за взлома, то отвечать будут по полной, «ой извините, баг» не прокатит (ибо регулируемая отрасль).
Речь шла про технику которая работает автономно и недоступна по интернету. Вам же наверняка известно, что почти в любом обычном (современном) автомобиле есть куча микроконтроллеров? А теперь расскажите как часто у вас отключается ABS сама по себе из-за багов. Ну а если отключится — то производитель будет отвечать очень даже материально. Мне лично неизвестен ни один случай, когда пришлось массово отзывать или перепрошивать серию машин из-за бага в firmware, а вам?
Поэтому я и предлагаю ввести ответственность за продукцию, если за это берут деньги — потому что сейчас от этого зависит жизнь, здоровье, благосостояние и т.п. Берешь деньги — давай гарантию, это честно. Накосячил так что потребитель пострадал — отвечай. В чём я неправ?
это не маркетинговый буллшит, а действительно так и есть, стоит только посмотреть на примеры которые я дал чуть выше.
Извините, но это именно маркетинговый буллшит. Толку с того на чём он focused, если писать будет криворукий программист? Ну не сможет он накосячить с памятью, зато накосячит в куче других мест. Даже хуже — криворукий подумает что ему вообще ни о чём думать не нужно, достаточно писать на этом языке (да, многие так думают) — и такого напишет… А для пользователя совершенно неважно как именно он накосячил — важно что «не работает как надо».
Все, абсолютно все без исключения баги (связанные с памятью или нет) — либо от криворукости, либо от невнимательности, либо от усталости, в общем как ни крутите — это вина разработчика (софта или железа), а не языка, так почему бы их не построить, или не контролировать и обучать жёстко?
Моё решение (либо исключить либо жётско контролировать человеческий фактор) универсально, а супер-мега-безопасный язык только создаст иллюзию решения проблемы, хотя решит всего лишь малую её часть.
D позволяет писать небезопасный код (как и Rust, при желании), но по умолчанию он довольно безопасный. GC это часть стандартного рантайма, его можно отключить (когда нужно) — если не использовать стандартный рантайм (если нужно ручное управление).
Потокобезопасность там достигается рантаймом и библиотеками, хотя если не использовать бездумно shared access (т.е. только обмен сообщениями с примитивами синхронизации) будет ровно то же самое что и в Rust.
Имеющийся код на C/C++ придётся именно переписывать на Rust (который ещё нужно изучить и понять, плюс поменять ряд концепций), в то время как в случае с D его придётся только адаптировать (хотя в случае C++ с тяжелыми темплейтами будет очень тяжко, они совсем разные).
Когда я начал изучать Rust, я понял что создание кода на нём это головная боль и существенно большие временные затраты по сравнению с C/C++/D/C#, не говоря уже об объеме кода (писать придётся больше при одинаковых задачах), а по сравнению с D/C# выигрыш весьма сомнителен (с точки зрения безопасности). К счастью, мне он нужен исключительно read-only (нужно сделать аудит одного проекта), это намного проще чем писать код.
Вы всё же почитайте про D на его сайте, вместо беглого гугления (это не займёт много времени) — и сравните с Rust, как по фичам так и по простоте использования (для сишников).
Формально доказано не совсем это, вы хотя бы просмотрите сей труд, что-ли. Не говоря уже о том что этот пруф базируется на предположении что используются только стандартный фреймворк и библиотеки, и делает ещё массу всяких допущений.
Сам по себе язык вполне допускает race conditions (их невозможно проверить статически, особенно если поведение программы в целом и потоков в частности зависит от внешних данных), да и документация не делает таких утверждений, даже наоборот:
So it's perfectly «fine» for a Safe Rust program to get deadlocked or do something nonsensical with incorrect synchronization. Obviously such a program isn't very good, but Rust can only hold your hand so far. Still, a race condition can't violate memory safety in a Rust program on its own. Only in conjunction with some other unsafe code can a race condition actually violate memory safety.
Грубо говоря, пока там есть unsafe код, то никаких гарантий нет и не может быть, не говоря уже о том что race conditions не ограничиваются некорректной синхронизацией обращения к памяти (а только от этого язык и спасает, по сути, и то если не использовать unsafe).
Тайпчекер и контракты хороши, если весь исходный код доступен и написан на одном языке, компилятору с которого можно всё рассказать. Но в приведённом мной примере Rust не помощник. Я не очень хорошо его знаю, но насколько я помню там нет контрактов — это величайшее упущение для «безопасного» языка (в то же время C# имеет pre-, postconditions и invariants).
При этом, проблема может и правда быть незначительной, просто её никто не увидит и не починит.
Если проблема настолько незначительна, что просто незаметна и не мешает программе выполнять свои функции — то какая же это проблема? Но вот «перехватить» порчу данных из-за неправильной работы с памятью (или алгоритма обработки) ой как непросто — данные таки будут испорчены, и скрыть это будет трудно. Равно как и «перехватить» уязвимость с проникновением — тоже практически нереально, она либо есть либо нет (и доказуема легко, если обнаружена).
Людям лень переписывать, а мир таки от этого лучше бы стал.
Переписывать с C/C++ на то что кардинально от него отличается по своим концепциям — это огромный труд.
Что мешало взять D в качестве безопасного языка, в крайнем случае допилить его если чего-то не хватает? Уж всяко проще было бы для любого сишника переписать на D, чем учить Rust и его зубодробительные отличия, при этом не имея возможности хотя бы частично использовать имеющийся код.
weird(int[] arr)
{
for (int n = 0; n < arr.length; n++) {
arr[arr[n] ^ 0x55] ^= 0xAA;
}
}
И как можно статически это проверить? А если условие не имеет отношения к индексу и/или размеру, и индексы вычисляются извне, то в начале цикла вообще нет смысла проверять. Пример конечно искусственный, но это чисто для демонстрации.
Поэтому в «безопасном» языке либо придётся «дуть на воду», либо явно отключать такие проверки прагмами или чем-то ещё (тоже тот ещё способ) — в конце концов, кто-то кто вызывает weird() может гарантировать что никакой элемент не будет больше чем 0xFF и что размер массива как минимум 256 элементов, а вот компилятор этого может и не узнать.
Трудно скрыть воспроизводимые ошибки типа «выполнил ряд действий — программа вылетела», а также уязвимости. В крайнем случае можно это задокументировать в присутствии нотариуса (или другим признаваемым законом способом, включая видеозапись).
Доказать что данные повреждены не пользователем тоже можно, как минимум косвенно, иначе бы Microsoft не признали что их апдейт удаляет данные, а Quora бы заявили что пользователи сами свои данные отдали.
И сейчас можно (белый список EXE и DLL-файлов, разрешённых к загрузке), но никто не делает, т.к. работать неудобно.
Там где критично — делают. Но можно сделать это так чтобы было максимально удобно и незаметно, хотя это и потребует усилий.
Мне кажется, даже в худшем случае это не приведет к таким проблемам, хотя и поколбасит некоторое время.
Во-первых, пряморукие разработчики всё же останутся, и смогут зарабатывать больше, по той простой причине что люди охотнее заплатят за софт зная что есть гарантии (я про ту часть мира где люди всё же привыкли платить за софт, если он платный).
Во-вторых, это стимулирует разработки в области ИИ для автоматизации либо написания программ, либо их качественной проверки на косяки, что приведет к безглючному софту. В крайнем случае, можно сделать качественные песочницы для популярных ОС, дабы минимизировать (или вообще убрать) последствия багов и уязвимостей, так чтобы никакой вирус или троян не смогли ничего сделать без явного разрешения пользователя (прощайте, вымогатели и вирусы).
Так что в долгосрочной переспективе это win-win, хотя может быть и неприятно некоторое время, особенно для криворуких.
По определению, никакой язык не в состоянии гарантировать ничего что выходит за рамки среды, которую он контролирует. Race может быть внешним, от языка не зависящим, он может быть gracefully processed (извините, не могу найти русский эквивалент), или может привести к проблемам. Собственно, про это явно говорится в документации к Rust.
Да, неопытные — большей частью. Тот факт что им удается сделать что-то работающим, нисколько не исключает тот факт что их способ — не самый оптимальный и не свободен от ошибок.
Это не значит что ничего не нужно делать, если не делать это хорошо — но факт остается фактом.
Неважно, сколько яда попадёт в ваш организм, если это смертельная доза. Мне, как потребителю, неважно, что программисты пофиксили 99% багов, если из за 1% отказали тормоза и я въехал в бетонную стену. Радуйтесь, что в большинстве случаев это не тормоза.
В этом и заключается проблема современных разработчиков.
Более чем 10 лет я писал write-only код, который вылизывался перед продакшн, потом работал более чем эти самые 10 лет без единой проблемы (и это был не Rust), и единственная поддержка в которой он нуждался — это хорошая документация. Увы, эти времена прошли, за последние 20 лет я не встретил (лично) никого кто был бы на такое способен. Печаль.
По пульсу и дыханию масса астматиков стала бы лжецами.
Профессиональные лжецы и жулики делают это естественно. Главное — верить в то что говоришь, хотя бы временно. Это тупиковая ветвь.
Далеко не каждый человек. Профессиональный лжец не задумается вообще, он выдаст мысль без задержки, и ему поверят. Даже ИИ.
Если человек верит в то что говорит, даже временно (пока говорит), отличить это от реальности невозможно. Все, кто утверждает обратное, просто жулики или дилетанты.
В конце концов, если бы это было возможно, то это бы уже давено применялось. Но практика показывает, что даже если целая банда психологов называет человека лжецом, это вовсе не факт. И наоборот тоже, соответственно.
Извините, не удержался…
Поздравляю — вы — розовый единорог. Или (всё ещё) очень неопытны. Хотя скорее всего, просто очень молоды. Даже если вам за 50.
Но не расстраивайтесь, либо это изменится через два-три десятка лет, либо вы придёте к этому в следующей жизни.
Хотя, в любом большом проекте с сотнями тысяч строк кода, не зная архитектуры приложения, не зная намерений разработчиков, не зная самого кода (внешний review) греп вам очень мало поможет.
Что касается других языков (любых) — нужно изначально писать код, который к ним не может привести. Пряморукий и опытный разработчик это сделает легко даже на ассемблере, причём на автомате, ему не нужна помощь компилятора.
Я не спорю что языки типа Rust снижают количество очевидных ошибок, но всё равно, большей частью речь только об ошибках связанных с обращением к памятью, в редких случаях других очевидных ляпах (типа присваивание вместо сравнения как в C, хотя это может быть и намеренно) — но это не решает проблему с багами в целом, это лишь уменьшит их количество (ненамного — C/C++ и прочие «небезопасные» языки и так мало где используются уже).
Если даже «прям щаз» всё что написано на C/C++ перепишут на Rust, это не сократит количество багов и уязвимостей даже на половину — по крайней мере, до тех пор пока разработчики не станут намного более квалифицированными.
В этом, собственно, и заключается моя мысль.
Одинаковые алгоритмы с одинаковыми структурами данных — да, будут равны. Например, простая функция которая возвращает сумму элементов целочисленного массива — написанная на Rust, C, C++ и хаскеле, пропущенная через LLVM — выдаст (с вероятностью 99,9%) одинаковый код. Если мы углубимся в объекты и тонкости их реализации с таблицами методов и прочими безобразиями — тут уже, скорее всего, будут отличия поболее.
Я вообще-то говорил не о простой «бытовой» технике, не зря сказал про автомобили — там практически нет багов в продакшн именно потому что производитель очень материально отвечает за их последствия. Насчёт жабы там сильно сомневаюсь, мощности и память не те. Впрочем, думаю, если найдут баг в микроволновке, которая взорвется или загорится из-за перегрузки, если в определенной последовательнсти нажать какие-то кнопки — то призводитель тоже ответит по самое не могу. А если розетка управляемая Алексой не включится — то да, никто не будет отвечать, хотя хз какие там будут последствия.
Я где-то сказал «неудобным»? Он просто не должен вставать у меня на пути, если я явно этого не хочу. Моя программа — я царь горы. Это инструмент. Если мне непосчастливится работать в компании где это обязательно (стреляющий за ляпы компилятор) — ок, другое дело. Но пока у меня есть выбор — я хочу им пользоваться.
Верьте или нет, но после первых 5 лет написания проектов на C, я научился не делать ошибок связанных с работой с памятью, валидация всего на входе, выходе и даже между ними у меня уже в крови, даже в наскоро написанных программах — зная о чём нужно думать, их легко избегать, особенно когда отладчик использовать невозможно и приходится всё держать в голове (да, в те далекие времена отладчики были роскошью, впрочем, как и наличие какого-либо компилятора C).
И чем мне тут помог бы Rust? Вы конечно скажете что я могу устать, опечататься etc — да, когда-нибудь это начнёт случаться. Но я глубоко уверен, что если человек начинает настолько уставать или становится невнимательным, что делает ошибки в коде (которые не замечает после первого перечитывания на свежую голову) — ему пора менять род деятельности, на тот где он не сможет делать ошибок, по крайней мере таких ошибок которые не сможет исправить до выкатывания продукции в прод.
Я не обвиняю, я указываю на источник проблемы. Как это ни прискорбно, но это из серии «нет человека — нет проблем». Поэтому идеальное решение — устранить из цепочки человека. Чуть менее идеальное — заставить его ошибаться почти никогда, или исключительно редко. Получается ведь у тех кто бомбы обезвреживает, почему не получится у программистов?
Давайте всё же не будем утрировать — я не такие драконовские меры предлагаю. А насчёт «никто не будет» — снова напомню про производителей автомобилей и прочей техники, где ответственность за баги весьма чувствительна (станки с ЧПУ и прочие промышленные роботы, как пример) — работают же, причём почти без багов. По крайней мере без таких которые явно ощутимы или даже хотя бы заметны. Причём, заметьте, автомобили при этом стоят вовсе не миллионы — эти микроконтроллеры и прочие embedded есть даже в дешевых авто.
Не хотите отвечать за содеянное — не берите деньги, а если уж берёте — то отрабатывайте и отвечайте за косяки. Я лично готов, а вы?
Там доказано, что в случае если мы будем использовать сферического коня в вакууме, то race не будет. Конечно, я утрирую, но они делают массу предположений о среде, библиотеках, etc. — а вы пишете «спасает от всех рейс кондишнов» — в то время как в труде говорится о конкретных, а не всех.
Мне казалось очевидным, что речь шла не про unsafe {NOP}. Речь шла о том что при желании, незнании (или неправильном знании, или малом опыте) race очень легко можно устроить, язык этого не предотвратит сам по себе.
Вот если бы ни при каких условиях, независимо от того как и какой пишется код, race были бы невозможны в принципе — тогда да, я бы с вами согласился. Но это, увы, не так.
Код коду рознь, а если у компиляторов один бэкэнд (LLVM) — то всё опять таки упрётся в дополнительные телодвижения (типа проверки индексов), которые оптимизацией невозможно убрать в ряде случаев, просто в принципе невозможно (см. мой пример выше).
Пример не совсем корректен — Тесла это сырой продукт, да и если докажут что авария случилась из-за взлома, то отвечать будут по полной, «ой извините, баг» не прокатит (ибо регулируемая отрасль).
Речь шла про технику которая работает автономно и недоступна по интернету. Вам же наверняка известно, что почти в любом обычном (современном) автомобиле есть куча микроконтроллеров? А теперь расскажите как часто у вас отключается ABS сама по себе из-за багов. Ну а если отключится — то производитель будет отвечать очень даже материально. Мне лично неизвестен ни один случай, когда пришлось массово отзывать или перепрошивать серию машин из-за бага в firmware, а вам?
Поэтому я и предлагаю ввести ответственность за продукцию, если за это берут деньги — потому что сейчас от этого зависит жизнь, здоровье, благосостояние и т.п. Берешь деньги — давай гарантию, это честно. Накосячил так что потребитель пострадал — отвечай. В чём я неправ?
Извините, но это именно маркетинговый буллшит. Толку с того на чём он focused, если писать будет криворукий программист? Ну не сможет он накосячить с памятью, зато накосячит в куче других мест. Даже хуже — криворукий подумает что ему вообще ни о чём думать не нужно, достаточно писать на этом языке (да, многие так думают) — и такого напишет… А для пользователя совершенно неважно как именно он накосячил — важно что «не работает как надо».
Все, абсолютно все без исключения баги (связанные с памятью или нет) — либо от криворукости, либо от невнимательности, либо от усталости, в общем как ни крутите — это вина разработчика (софта или железа), а не языка, так почему бы их не построить, или не контролировать и обучать жёстко?
Моё решение (либо исключить либо жётско контролировать человеческий фактор) универсально, а супер-мега-безопасный язык только создаст иллюзию решения проблемы, хотя решит всего лишь малую её часть.
Потокобезопасность там достигается рантаймом и библиотеками, хотя если не использовать бездумно shared access (т.е. только обмен сообщениями с примитивами синхронизации) будет ровно то же самое что и в Rust.
Имеющийся код на C/C++ придётся именно переписывать на Rust (который ещё нужно изучить и понять, плюс поменять ряд концепций), в то время как в случае с D его придётся только адаптировать (хотя в случае C++ с тяжелыми темплейтами будет очень тяжко, они совсем разные).
Когда я начал изучать Rust, я понял что создание кода на нём это головная боль и существенно большие временные затраты по сравнению с C/C++/D/C#, не говоря уже об объеме кода (писать придётся больше при одинаковых задачах), а по сравнению с D/C# выигрыш весьма сомнителен (с точки зрения безопасности). К счастью, мне он нужен исключительно read-only (нужно сделать аудит одного проекта), это намного проще чем писать код.
Вы всё же почитайте про D на его сайте, вместо беглого гугления (это не займёт много времени) — и сравните с Rust, как по фичам так и по простоте использования (для сишников).
Сам по себе язык вполне допускает race conditions (их невозможно проверить статически, особенно если поведение программы в целом и потоков в частности зависит от внешних данных), да и документация не делает таких утверждений, даже наоборот:
Грубо говоря, пока там есть unsafe код, то никаких гарантий нет и не может быть, не говоря уже о том что race conditions не ограничиваются некорректной синхронизацией обращения к памяти (а только от этого язык и спасает, по сути, и то если не использовать unsafe).
Если проблема настолько незначительна, что просто незаметна и не мешает программе выполнять свои функции — то какая же это проблема? Но вот «перехватить» порчу данных из-за неправильной работы с памятью (или алгоритма обработки) ой как непросто — данные таки будут испорчены, и скрыть это будет трудно. Равно как и «перехватить» уязвимость с проникновением — тоже практически нереально, она либо есть либо нет (и доказуема легко, если обнаружена).
Переписывать с C/C++ на то что кардинально от него отличается по своим концепциям — это огромный труд.
Что мешало взять D в качестве безопасного языка, в крайнем случае допилить его если чего-то не хватает? Уж всяко проще было бы для любого сишника переписать на D, чем учить Rust и его зубодробительные отличия, при этом не имея возможности хотя бы частично использовать имеющийся код.
И как можно статически это проверить? А если условие не имеет отношения к индексу и/или размеру, и индексы вычисляются извне, то в начале цикла вообще нет смысла проверять. Пример конечно искусственный, но это чисто для демонстрации.
Поэтому в «безопасном» языке либо придётся «дуть на воду», либо явно отключать такие проверки прагмами или чем-то ещё (тоже тот ещё способ) — в конце концов, кто-то кто вызывает weird() может гарантировать что никакой элемент не будет больше чем 0xFF и что размер массива как минимум 256 элементов, а вот компилятор этого может и не узнать.
Трудно скрыть воспроизводимые ошибки типа «выполнил ряд действий — программа вылетела», а также уязвимости. В крайнем случае можно это задокументировать в присутствии нотариуса (или другим признаваемым законом способом, включая видеозапись).
Доказать что данные повреждены не пользователем тоже можно, как минимум косвенно, иначе бы Microsoft не признали что их апдейт удаляет данные, а Quora бы заявили что пользователи сами свои данные отдали.
Там где критично — делают. Но можно сделать это так чтобы было максимально удобно и незаметно, хотя это и потребует усилий.
Во-первых, пряморукие разработчики всё же останутся, и смогут зарабатывать больше, по той простой причине что люди охотнее заплатят за софт зная что есть гарантии (я про ту часть мира где люди всё же привыкли платить за софт, если он платный).
Во-вторых, это стимулирует разработки в области ИИ для автоматизации либо написания программ, либо их качественной проверки на косяки, что приведет к безглючному софту. В крайнем случае, можно сделать качественные песочницы для популярных ОС, дабы минимизировать (или вообще убрать) последствия багов и уязвимостей, так чтобы никакой вирус или троян не смогли ничего сделать без явного разрешения пользователя (прощайте, вымогатели и вирусы).
Так что в долгосрочной переспективе это win-win, хотя может быть и неприятно некоторое время, особенно для криворуких.