-
Язык, ограничивающий работу с сырой памятью, сырыми аллокациями, сырым владением - уже есть внутри C++: это такое его подмножество, где аллокации заменены на make_shared-подобное, сырая память/ресурсы - на всякие там контейнеры/инкапсуляции/RAII, владение - на смартпоинтеры и подобное. Если я как-то «нормально» знаю C++, включая и «сырое» и «хорошее», то получается мне не надо осваивать никакой другой язык, чтобы начать пейсать не-говно. Зачем вводить в инструментарий что-то ещё, если такое уже есть? Отказаться от C++ в пользу Rust - это какой-то сложный манёвр, совершаемый гораздо проще не уходя от C++ и не ДОБАВЛЯЯ ничего нового, а только УБИРАЯ что-то: достаточно отказаться от ЧАСТИ C++, не изучая ничего нового вообще. Не пиши на C++ и пиши на Rust - это строго сложнее и страннее, чем «пиши на С++, но без сырых указателей и сырых аллокаций». Rust уже есть внутри C++, что моментально заненужнивает какой-то отдельный Rust. Более того, для начала можно даже не ходить так далеко как отказ от куска C++, а взять свежайший C++ компилятор, врубить последний стандарт, врубить все параноидальные warning по максимуму, приравнять их к ошибкам компиляции (-Werror) и компилятор подробно расскажет тебе, какая ты дура, пока не перепишешь нормально.
-
Ясно, что Rust нужен, чтобы набрать много макак с рынка, которые ПРИ ЖЕЛАНИИ не смогут сломать память. Теоретически, вредное подмножество Rust (unsafe) в разы меньше, чем вредное подмножество C++. По задумке, ревьюить Rust - проще, ведь надо просто отследить наличие unsafe, а ревьюить C++ макака не может. Ну ХЗ - в статический анализатор кода запихнул правила забраковки кода с сырыми указателями в С++ и готово. Ну и последний совет из пункта (1) даст 100 лет строгача с конфискацией за малейшую попытку побега - всё как в Rust: небезопасненько: не соберётся.
-
Но Rust не простой, под него макака не подходит изначально. Rust варится в такой же задротской атмосфере, как и C++. Для макак инструмент надо ещё более тупой - что-то типа JS, где «что ни написал - всё работает», а к памяти доступа ВООБЩЕ нет ни через какое волшебное слово (unsafe). Если надо, чтобы быстро исполнялось, то в бинарный код мы уж как-нибудь скомпилируем/оттранслируем любой кал - в пределе (в прекрасной России будущего) волшебные оптимизаторы LLVM разрулят всё неоптимальное, что макака написала. Транслируем любой макачий кал в строго корректный машинногенерируемый С++ и его скомпиляем.
-
Даже из принципа нужности управления битиками в крайне узкоспециальной части проекта мне не нужно много гениев. А это «мало гениев» я наберу с рынка вообще без проблем - и по зарплате там не сильно важно в чём он там гений - C++, Rust. Rust-задроты даже больше просят из-за модности.
-
Супер железное правило, которое не перебивается вообще ничем логически: если вы затеяли лабать что-то уровня собственной СУБД с транзакциями и запутались в циклических ссылках, то вы уже давно перешли порог гениальности, после которого вам уже вообще насрать на чём это пишется. Эпичный баг, который вы будете искать дольше суток, с утечками/циклическими ссылками/порчей памяти вы в этом большом проекте поймаете за жизнь 2 раза от силы, остальное проблемное какой угодно сложности вы в дебаггере отловите за пару часов и это будет случаться раз в полгода - вообще экономически не повод менять инструмент. Да и то, затрачиваемое время на поиск багов растянется только потому, что на вашем уровне развития вы не могли пройти мимо очередного срача «C++ vs Rust» и отвлеклись на 4 часа от дебаггера.
UPDATE
Мне накидали в панаму разумных куёв, поэтому давайте выведем топик на новый уровень. Напишите не суперсложный кусок кода на C++, который потенциально вызывает проблемы и тот же кусок кода на расте, который никак не бомбанёт.
