Rust vs C: кто реально выигрывает в embedded?

Слушай, я с тобой на 100% в плане реалий embedded с 2КБ RAM — там Rust действительно выглядит как слон в посудной лавке. Я как QA перелопатила кучь проектов на STM32 и AVR, и видела эти попытки «безопасно» обернуть HAL или CMSIS в unsafe. В итоге получается, что borrow checker в embedded — это не спасение, а головная боль, когда ты работаешь с регистрами и DMA, где вся логика — это глобальное состояние и side effects. Ты прав: C даёт тебе прозрачность каждого такта, а Rust добавляет слой абстракции, который в реальных лимитах по памяти и времени часто просто не нужен. Но я бы чуть смягчила: для прототипов или проектов с избытком ресурсов (например, Cortex-M4 с 256КБ RAM) Rust может быть удобен, особенно если команда боится утечек и UB. Но на голом железе с 2КБ — это мазохизм, согласна. Так что король тут C, а Rust — интересный эксперимент для тех, у кого есть запас по RAM и тактовой частоте.

Слушай, я в целом на твоей стороне, но с парой оговорок. Да, на STM32F0 или AVR с 2КБ RAM Rust превращается в цирк с макросами: тебе приходится выстраивать целые пайплайны из типов-состояний, чтобы borrow checker не рыдал над регистрами DMA, а в итоге всё равно упираешься в unsafe для работы с прерываниями и отображением памяти. Я сам пробовал затащить Embassy на Cortex-M0 — код получился элегантным снаружи, но внутри там такие слои абстракции, что отладка стека превращается в квест. С C ты просто пишешь `*(volatile uint32_t*)0x40020014 = value` и чётко знаешь, что происходит за каждый такт. Но я бы не списывал Rust со счетов для embedded целиком. Для проектов посложнее, где есть Cortex-M4F с 256+ КБ RAM, он реально вывозит: аллокатор можно выключить, borrow checker ловит use-after-free в драйверах, а `#[derive(RTIC::app)]` даёт хорошую модель для прерываний без гонок. Проблема в том, что хайп вокруг Rust для голого железа часто игнорирует ту самую «цену абстракции» — на порядок больше кода в результирующем бинарнике и зависимость от кривых скриптов линковки. Так что король C пока на троне, но Rust — это не игрушка, а скорее экспериментальный джокер для тех, у кого бюджет по RAM и нервам позволяет.

Слушай, я с тобой согласен насчёт 2КБ RAM — там Rust реально не в своей тарелке, я как QA видел эти попытки обернуть CMSIS в unsafe, и получается, что borrow checker просто мешает, когда ты работаешь с регистрами и DMA. C даёт тебе прозрачность каждого такта, и это бесценно для голого железа. Но я бы не списывал Rust полностью: на Cortex-M4 с 256КБ RAM, где есть запас, он реально вывозит, ловя use-after-free в драйверах и давая модель прерываний без гонок через RTIC. Проблема в том, что хайп часто игнорирует цену абстракции — бинарник раздувается, линковщик глючит, а на малых ресурсах это превращается в цирк. Так что C — король для лимитированных систем, а Rust — интересный джокер для проектов с бюджетом по ресурсам и нервам.

Слушайте, я понимаю аргумент про 2КБ RAM и прозрачность C — это правда работает как часы на голом железе. Но давайте без фанатизма: Rust на Cortex-M0 с 2КБ — это да, цирк, но кто в здравом уме потащит туда Embassy или async-рантайм? Проблема не в языке, а в том, что люди пытаются скопировать подходы из веба в embedded, не думая о лимитах. Я сам видел проекты на Rust для STM32F0, где финальный бинарник меньше, чем у C, потому что LLVM выкидывает мёртвый код агрессивнее GCC, а unsafe блоки для регистров — это не «обёртка над C», а просто работа с volatile указателями, как и в C, но с гарантией, что ты не забыл volatile. Так что C — король для простых тасок, где важна каждая микросекунда. Но на Cortex-M4 с 256КБ RAM Rust реально вывозит в многопоточных драйверах и сложных стейт-машинах, где borrow checker отлавливает гонки, которые ты на C будешь неделями дебажить. В итоге выбор упирается в бюджет: ресурсы есть — бери Rust для надёжности, нет — C для контроля. И не надо называть Rust игрушкой — это просто другой инструмент для другой задачи.