Ребята, я тут на днях решил покопаться в Rust после того, как очередной юный энтузиаст заявил, что он «безопаснее C». Ну да, конечно. Потратил час, чтобы разобраться с borrow checker, который рыдает на каждой строчке, а в итоге получил бинарник, который жрёт в два раза больше памяти, чем мой старый добрый код на C. Где тут профит, а? В C я хотя бы знаю, за что плачу — каждый байт на вес золота, а тут какие-то абстракции для школьников.
И давайте честно: все эти «нулевые затраты» — маркетинговая уловка. Попробуйте написать драйвер на Rust без unsafe блоков — вас засмеют. А с unsafe вы просто имитируете C, только с компилятором, который ноет как пятилетка. Не проще ли сразу взять C и не париться? Или мы уже забыли, что такое реальная оптимизация?
Жду аргументы от фанатов, только без ссылок на документацию — я её читал и считаю, что это просто способ продать новый язык тем, кто боится указателей. Ну и где ваши «безопасные» проекты, которые не тормозят? Покажите мне хоть один, который не съедает всю RAM.
👍 1
Ну давай разберем твою претензию по пунктам. Про borrow checker — да, он бесит, когда привык к C и ручному управлению памятью. Но проблема не в том, что он «ноет», а в том, что ты пытаешься писать на Rust как на C с синтаксисом посовременнее. Это путь в никуда. Rust требует другого подхода к проектированию данных и владению, и если ты не готов перестраивать голову — да, проще остаться на C. По памяти: накладные расходы в 2x — это либо кривые абстракции вроде Box<dyn Trait> на каждом шагу, либо ты сравниваешь отладочную сборку с релизной оптимизированной C. В релизе Rust умеет выбрасывать большую часть этого мусора, если не лепить идиотские умные указатели без нужды.
По unsafe — да, это костыль для FFI и железа, но его доля в реальных проектах обычно меньше 5% кода. Вся соль не в том, чтобы вообще не использовать unsafe, а в том, что компилятор заставляет тебя явно отмечать потенциально опасные места, в отличие от C, где любой memcpy — потенциальная дыра. А про «безопасные проекты без тормозов» — глянь на Firecracker от AWS или ядро Redox OS. Они не жрут RAM просто потому, что там не пишут на коленке, а проектируют архитектуру под модель владения. С C та же история: если наклепать кучу глобальных мутексов и динамических аллокаций — и C будет тормозить.
Слушай, я в целом согласен с посылом, но с парой уточнений. Термин «C с багажом хайпа» — это просто кликбейт для тех, кто не осилил borrow checker и теперь ищет оправдания. Rust — это не C с навесными заморочками, а принципиально иная модель управления памятью, которая требует перепроектирования архитектуры. Если ты пишешь на Rust так, будто это C с RAII — да, получишь кучу лишних проверок и накладных расходов на умные указатели. Но если изначально строить граф владения без лишних Rc/RefCell и избегать динамической диспетчеризации там, где достаточно мономорфизации, — разница с C будет в пределах погрешности, особенно на современных компиляторах.
По unsafe — это вообще странный аргумент. Да, он существует, и его доля ничтожна в нормальных проектах. Но суть не в том, чтобы его избежать любой ценой, а в том, что он явно маркирован и аудируется, в отличие от C, где вся кодовая база — сплошной unsafe без таблички. Так что если твой собеседник реально видел проекты на Rust с двукратным перерасходом памяти — это не проблема языка, а проблема проектирования и, скорее всего, злоупотребления абстракциями уровня «лишь бы скомпилировалось». В C такие же грабли дают не меньший прирост потребления, просто там это списывают на «ну так исторически сложилось».
