> 1. Вы делаете туже ошибку, что создатели Rust. Гарантии безопасности может дать
> только ядро OS и процессор. При этом компилятор очень важен для
> обеспечения безопасности. Но компилятор не есть ключ к гарантиям безопасности.

Нет, я не делаю ошибок. Это ты мыслишь админскими категориями, а не программерскими.

> 2. Вы недоконца поняли проактивную защиту, она не только заменяет дыру на
> DoS.

Это если эта проактивная защита сработает. Более того, где сработает проактивная защита? Там где ты совершил ошибку в коде? хехе, нет. Она сработает там, где код разадресовывает dangling pointer, а не там, где ты создал этот dangling pointer. У тебя в логах есть бектрейс? Или даже у тебя есть core dump? Успехов теперь угадать, каким образом этот dangling pointer был создан. Тот стековый фрейм, на котором он был создан, был удалён со стека, может быть за трое суток до того, как этот dangling pointer был разадресован. Более того, может быть ещё более мозговыносящая ситуация: dangling pointer был создан, потом двое суток он не использовался, и поэтому не создавал проблем, потом он начал использоваться, но волею случая он указывал в место, где был выделен какой-то другой объект, и таким образом все эти твои проактивные защиты не видели в этих разадресациях ничего плохого, они считали, что всё ок: указатель ведь в выделенную память указывает? Если тебе повезло, то указатель использовался только для чтения из памяти. А потом этот объект был удалён, и следующее использование dangling pointer'а привело к панике и core dump'у. Если тебе не повезло, то ситуация может быть ещё более мозговыносящей: твоя программа делала что-то типа dangling_pointer->id = 234897, это поле id попадало на поле ptr какой-то структуры, и ты по факту создавал _новый_ dangling_pointer, и в core dump твоя программа упала тогда, когда тот ptr разадресовывался.

А вот теперь, попробуй найти ошибку, которая привела ко всему этому. Я где-то как-то читал о замечательном баге, который выскакивал в программе совершенно непредсказуемо _годами_. Были десятки багрепортов о нём, но найти его никто не мог. И все твои проактивные защиты были бесполезны против него. Если тебе приходилось когда-нибудь пару дней отлаживать C'шную программу, выискивая то место, где ты забыл обнулить указатель, или может быть ты забыл не обнулить его, а индекс неверно высчитал? Или может там переполнение целого где-то случилось? Или, блин, ты не к тому типу привёл void*? Или может ты наступил на грабли UB, и поэтому проверка на NULL как бы и есть в сорце, но её как бы и нет в машинном коде? Если тебе приходилось ковыряться пару суток вокруг такой хрени, то как ты вообще можешь верить в проактивные защиты? А если не приходилось, то это говорит лишь о том, что ты никогда не писал на C, и тогда непонятно, что позволяет тебе верить в действенность защит со стороны ядра или, если уж на то пошло, в ненужность rust'а.

Все твои рантайм защиты со стороны ядра нацелены лишь на то, чтобы сделать _эксплуатацию_ таких вещей сложнее. При этом они не дают гарантий, эти защиты недоказуемы. Они усложняют атаки, очевидно, но не делают их невозможными. Поскольку они усложняют, может быть и имеет смысл их использовать, пока они не приводят к существенным пенальти в сторону производительности. Но если ты хочешь делать атаки невозможными, тебе надо сделать невозможными вот те сценарии, которые я описал выше.

> 4. Если интересует компилятор проверяющий индексы можно посмотреть Fortran, Pascal.

Да мне похрен на индексы, ты понимаешь это? Проверка индекса на выход за границы -- это лишь малая часть, того что даёт rust, и реализована она в библиотечном коде с опорой на другие возможности языка, которые позволяют реализовать такое в библиотеке, оформив это няшным и удобным для использования API. То есть, ты вот явно непонимаешь о чём речь, я поясню на примере. Допустим мне вдруг стало неинтересно, что массив паникует, когда я выхожу за границы его. Допустим я решил, что я знаю как обрабатывать в рантайме такую ошибку. Ты понимаешь, что я могу взять и изменить slice таким образом, чтобы index возвращал бы Result? Да, потом мне придётся писать
"arr[i]?" вместо "arr[i]", хм... но и чё? Ну-ка расскажи мне, как я могу паскаль научить не падать с рантайм-ошибкой при выходе за границы массива?

Я тебе очень рекомендую не рассуждать о расте на основании маркетинговых материалов, а взять и попробовать. Просто заценить как это круто, когда все сообщения об ошибках, как compile-time, так и runtime указывают тебе в то место, где ты совершил ошибку, а не в рандомное место соседнего процесса^W^W... ок, в соседний процесс оно не указывает никогда, но ты понял суть, да?