Я смотрю ты очень избирательно читаешь или не понимаешь написанного.

Это типичные проблемы junior программистов и фанатиков.

Расскажи мне, где ты увидел что

> Это еще раз показывают качество твоих знаний про Раст.

Я говорил что проверок выхода за границы нет в Rust?

> Ты написал целую кучу про дефер, но так и не сказал это "hidden control flow" или нет.

Это не hidden control flow.

> Ого! да у нас тут гуру, ты не стесняйся продолжай что еще является костылями?

Представляешь, деструкторы часто не нужны. Понимаю, такие тайные знания не всем под силу.

Например, не вызывать деструктор на объекте после std::move(val). Понимаю, такому наверное не учили.

> Такая необходимость возникает в очень редких задачах типа БД.

Это возникает в любом высокопроизводительной задаче, HPC, браузерные движки, базы данных, и тд. Если ты гоняешь json-чики на Rust (или С++), то конечно обновляй всё подряд, что нужно и не нужно 😆

> Для обычной разработки память должна обнуляться чтобы потому bufferoverflow

Откуда у тебя там buffer overflow возникнет?) Это надо быть рукожопом. Меняешь size на 0, массив логически пустой. Индексы при вставки тоже проверять нужно. Вот такие рукожопы потом и говнокодят, что на С++, что на Rust.

Я смотрю и Rust особо от рукожопов не спасает 😆

Если ты обнуляешь данные - ты скрываешь ошибку, и на тестах хрен ты её потом отловишь, в отличии от "грязного" буфера.

Но я так понял тут у нас Rust эксперт, который в массив с обычными данными ещё и пароли записывает 😆😆😆

Вот ты и расписался в своей абсолютной некомпетентности. Ты как говнокодил на языке Н, так и на Rust продолжаешь говнокодить 😆

И как мы видим никакой Rust тебе не помог, ошибки твои не выловил, по рукам не дал. Зато "безопасно". От дураков защиты нет.

> Хм... ну так начнем с ошибок которые можно словить, а потом может что-то придумаем.

Это умеет делать одинаково хорошо и С++. И zig.

Твой borrow checker - он не находит ошибки, как ты до сих пор понять то этого не можешь. Остальное не отличается от других языков.

> Очень голословное утверждение особенно на фоне того что разрабы ЗИГа сами пишут "not fully safe".

Зато капсом, так наверное более убедительно.

Я достаточно привёл аргументов. И доказал убедительно с фактами. Понимаю, неприятно их признавать.

Твой фанатизм затмил тебе глаза, ты как сектант теперь.

Конечно Zig не полностью безопасный язык. Там есть сырые указатели. Как и в Rust, но он у тебя полностью безопасный 😆😆😆 Самому то не смешно?)))

> А насколько это необходимо? Насколько это влияет на безопасность?

Примеры пожалуйста.

Кастомный аллокатор в 30-60 раз быстрее обычного глобального, потому что он потокобезопасный, у него куча внутренних структур и локов.

Это нужно там где 1. важна скорость 2. важны гарантии - микроконтроллеры, любое критичное ПО на Linux. 3. ты можешь какому-то коду давать специальные аллокаторы

Они используются в браузерах, базах данных, языках программирования. У меня друг в мировой компании разрабатывает язык программирования - у них специальные аллокаторы в runtime.

> When a safety check fails, Zig crashes

Там где программа в состоянии, где больше ничего нельзя сделать. Например выход за границы массива. Вместо того чтобы потихому прочитать невалидные данные он упадёт. Это и есть безопасность.

> Сразу видно уровень качества разработки, у нас будет креш по памяти, но ты об этом не узнаешь)
> Memory TODO

Ну зачем ты так нагло и некрасиво врёшь? Я специально посмотрел документации master и 0.11. Там ничего такого нет. Все TODO - это в основном добавить документацию.

Как это не узнаешь? А все те проверки это что по твоему?) А выход за границы массива, а memory leak sanitizer???