> Это все как бы замечательно, но подразумевая что речь идет про embedded(а
> где еще no_std нужно?), что ты там собрался из Cargo добавлять,
> если памяти обычно кот наплакал и каждый байт на счету?Embedded разный бывает, гляньте хоть на то, что есть за таргетом thumbv7em-none-eabihf (Flipper Zero как близкий лично мне пример того, что я сам руками трогал и для чего сам собирал растовые приложения). Но важно не это, а то, что:
> Раст известен своей способностью генерировать бинарники большого размера и во встройке это
> обычно не приемлемо.
Он их генерит тогда, когда от него это просят (с поправкой на дефолты для std, где по умолчанию достаточно много дебажной инфы [^1]). И в условиях no_std это всё ещё не проблема, потому что у разработчика всё ещё есть контроль над тем, что именно происходит при билде (что как линкуется, что (не) стрипается и т.д). В конце концов, из коробки есть [1] два режима оптимизации под минимальный размер.
Например, у меня прекрасно билдится 5336-байтная аппа динамически линкующаяся к API Flipper Zero и использующая его API для GUI.
> Знаю есть какой-то микрораст
Нету такого. Вероятно, путаете с Go. Есть [2] MDBook с таким названием, но жэто всё ещё рассказ об обычном Rust, а не какой-то его другой версии.
`no_std` Rust (и даже `no_core`, но это уже совсем нишевое нечто) это всё тот же Rust, с теми же гарантиями, с тем же тулингом (с поправкой на поддержку конкретных таргетов, и то, там всё более чем хорошо [3]).
> или же обычный можно
> оптимизировать отключив проверки, но тогда он принципиально ничем от C не
> отличается, так как пришлось пожертвовать его главными преимуществами.
Какие проверкаи? Debug assertions итак отключаются в релизных сборках (на то они и debug assertions). А борроу чекер (а кроме него раст ценен, вообще, системой типов и просто языковыми фичами) нельзя отключить. Ну просто нельзя, это часть языка, а не опциональная штука.
Это распространнённое заблуждение, что unsafe кого-то там отключает. В unsafe лишь доступны *другие* [4] действия (таким, для которых компилятор не сможет проверить инварианты, и для которых ответственность за соблюдение осознанно перекладывается на плечи разработчика).
И для embedded'а (как и, вообще, разработки низкоуровневых библиотек на Rust) в этом идея: *один раз* написать безопасный обёртки над некоторым небезопасным кодом, и дальше ими пользоваться бнз всякого unsafe. Чем мы (в свободное время) занимаемся разрабатываея упомянутые ранее биндинги для Flipper Zero [5]. Чем другие люди занимаются, делая разного рода либы (включая рахного рода HALы).
Да, это всё ещё не панацея (а что ей является из массово применимого&применяемого?). Да, разработчик может ошибиться в реализации unsafe-части обёртки, и тогда никаких гарантий нет, но это не менее справедливо для кода на том же C, где, однако, эту небезопасную часть синтаксически ничто не локализует, в отличие от Rust, где, по крайней мере, фокус ревью, комментариев по инвариантам и санитайзеров, валидаторов, интерпретаторов (см. MIRI [6]) вместо того, чтобы рассматривать вообще всю кодовую базу как минное поле.
[^1]: И то, эти дефолты меняются в лучшую сторону, о чём есть прекрасная статья [7].
[1]: https://doc.rust-lang.org/cargo/reference/profiles.html#opt-...
[2]: https://droogmic.github.io/microrust/
[3]: https://doc.rust-lang.org/beta/rustc/platform-support.html
[4]: https://doc.rust-lang.org/std/keyword.unsafe.html
[5]: https://github.com/flipperzero-rs/flipperzero
[6]: https://github.com/rust-lang/miri
[7]: https://kobzol.github.io/rust/cargo/2024/01/23/making-rust-b...
