Rust: переваги і недоліки. Що пропонує ця мова для IoT-проєктів
Привіт, спільното DOU. Мене звати Михайло Майдан, я — Head of Rust department у Yalantis, а також Rust-євангеліст з багатьох причин. У компанії наразі ми маємо декілька поточних проєктів у секторі зеленої енергетики, медичного та промислового ІоТ з глибокою експертизою використання Rust. До цього я мав пʼять років досвіду роботи Embedded Engineer з використанням C/C++.
Сьогодні я розповім про те:
- як ми можемо використовувати Rust з Internet of Things;
- як Rust може допомогти цьому домену, а також як правильно вибрати мову програмування під IoT;
- подивимося невеликий приклад з практики, який я підготував;
- FAQ.
Технологія IoT зараз
Згідно зі звітом від Gartner, до кінця 2020 року у світі вже було близько 20,4 мільярда підімкнених пристроїв IoT. За прогнозами, ця кількість зросте до 30 мільярдів до 2025 року, а деякі оцінки навіть вказують, що до 2026 року це число може сягати 75 мільярдів. Глобальний ринок IoT очікувано перевищить 1,5 трильйона доларів до 2030 року, що свідчить про його величезний вплив на промисловість.
З розширенням сфери застосування IoT зростає потреба в міцних та надійних технологіях. Тут велику роль відіграють мови програмування, які є основою розробки IoT. Серед них Rust, відомий своєю увагою до безпеки та продуктивністю.
Сьогодні я пропоную глянути трохи під капот пристроїв, які називаються Things і є основою IoT. Типовий пристрій під IoT — це мікрочип з обмеженими: ресурсами, пам’яттю, а також швидкістю та потребою в енергоефективності. Багато таких пристроїв працюють на батарейках і потребують оптимізованих прошивок для довгого терміну служби батарей та пристрою в цілому.

На сьогодні для таких пристроїв вигідно використовувати три основні мови програмування, причому дві з них вибиваються у лідери — С та С++. Тобто 99,9% випадків прошивки під ІоТ-девайси, написано на C або C++, бо вони безпосередньо дозволяють працювати напряму з hardware.
Ці мови надають можливість manual memory management, що дозволяє розробникам ефективно керувати пам’яттю та використовувати ресурси пристроїв. Також варто відзначити MicroPython, оптимізовану версію Python для написання прошивок для embedded-пристроїв. Однак попри це, основні мови для розробки вбудованих систем — C і C++.
Ну і написання коду на Assembler вважається складним завданням і рідко використовується у комерційному програмуванні через його високі витрати та неефективність. Хоча деякі вставки Assembler можуть розв’язувати певні проблеми, основна частина коду залишається на C або C++.
Оскільки С/C++ мають певні проблеми (з якими вже борються багато років) і вони можуть призводити до серйозних похибок через неправильну поведінку або помилку програміста, що дуже ймовірно, зважаючи на складність мов, індустрія давно шукає технологію, яка дозволить розв’язувати проблеми С/C++ і водночас отримати максимум ефективності. Такою технологією є Rust.
Особливості Rust
Тепер перейдемо до молодого та перспективного Rust, який з’явився на ринку і пропагується як мова системного рівня, що підтримує multi-paradigm підхід. У Rust є Zero-Cost Abstraction, що також присутнє в C++, що дає можливість реалізовувати різні абстрактні конструкції та не платити за їхнє використання — швидкодією.
Що насправді цікаво, це те, що коли Rust вперше була запропонована Грейдоном Гоаром в компанії Mozilla, мова відразу почала набирати популярність, оскільки знаходила рішення для проблем, яким було вже по 30 років і які ніяк не могли вирішити в С/C++. Ці проблеми зазвичай призводили до втрати грошей, що само собою зацікавило бізнес.
Наприклад, проблеми з Undefined Behaviour та Memory Leak коштують дуже дорого. Вам потрібна дуже досвідчена команда для написання високоякісного ПЗ. Помилка програміста, як і дебагінг, може коштувати дуже дорого.
Rust виник як свіжий подих та повна сподівань технологія, яка може розв’язувати проблеми, над якими працюють протягом десятиліть.

Припустимо, ми маємо дуже простий IoT- пристрій, нам потрібно, щоб мова забезпечувала безпеку на всіх рівнях і не мала ситуації, коли код може аварійно завершитися через некоректні операції з пам’яттю. Для складніших IoT-девайсів важлива підтримка real-time операційних систем.
Тут також важливо мати розвинену екосистему для мови програмування, що дозволить вибирати серед різноманітних бібліотек та фреймворків. Це показує розвиток мови, якщо ком’юніті й екосистема мови зростає, особливо опенсорсна частина.
Розширення комʼюніті та підтримка великими компаніями, як-от Microsoft та Google, також свідчать про потенціал мови. Однією з переваг є також наявність сучасних функцій, таких як паттерн-матчинг, які можуть бути відсутні в інших мовах програмування, як-от C чи C++.
Недоліки Rust
Якою б прогресивною не була мова Rust, вона все-таки має недоліки, про які треба знати й мати на увазі, якщо є бажання свічнутися.

Складність вивчення: дехто говорить, що для тих, хто володіє C++, вивчення Rust може бути легше, оскільки вони вже ознайомлені з певними парадигмами та підходами, що використовуються в плюсах. Насправді Rust має дуже багато нових концепцій, які в інших мовах або не використовуються, або не такі популярні, що робить Rust трохи складнішим у вивченні.
Обмежена кількість якісних бібліотек: бібліотек специфічних для IoT у порівнянні з мовами, такими як C та C++ — дуже мало або вони не достатньо протестовані.
Відсутність достатньої кількості кваліфікованих фахівців: знайти спеціалістів, які володіють глибоким розумінням мови та її екосистемою, наразі не так легко. Підходи, що вже роками вдосконалюються в інших мовах програмування, можуть ще не бути налагодженими в Rust. Відсутність кваліфікованих кадрів впливає на час розробки і, відповідно, на вихід в реліз. Також невеликий розмір Developer Community порівняно з іншими мовами, такими як C чи C++, може впливати на доступність якісної інформації та рішень щодо проблем в Rust.
Хоча Rust має невелику, але дружню спільноту, яка постійно росте, наявність форумів та ресурсів для отримання інформації про проблеми ще не така розгалужена, як в C чи C++. Спільнота Rust наразі значна і постійно зростає, порівняно з іншими мовами програмування, але наразі це може розглядатися як недолік, оскільки менша кількість експертів та ресурсів може уповільнити розвиток мови.
Обмежений тулінг для роботи з різними апаратними пристроями. Хоча ці інструменти активно розвиваються, виробники апаратного забезпечення пишуть свої тули для роботи з власними пристроями.
Це позитивний аспект, оскільки це сприяє взаємодії мови з різноманітними мікроконтролерами. Проте на цьому етапі підтримка обмежується лише найбільш популярними виробниками, як-от STM, ISP, і Arduino. Інші чипи, можливо, не так широко підтримуються. Але слід зауважити, що це є тимчасовим явищем, і згодом ми можемо очікувати розширення підтримки для інших виробників чипів та апаратних пристроїв у мові Rust.
Переваги Rust

Memory Safety: Rust однозначно виграє в цьому сенсі, оскільки підходи, використовувані в C і C++, часто є застарілими, особливо в C. Навіть у C++, залежно від практик програмування, ситуація може бути кращою за C. У Rust Memory Safety вбудована на рівні типів та ownership-моделі, що сприяє написанню безпечного коду без використання ручного видалення пам’яті. Однак, у C++ також можна досягти безпеки, використовуючи сучасні підходи та принцип RAII.
Concurrency Support: у Rust це є стандартною можливістю, тоді як у C++ це може вимагати додаткових зусиль та використання бібліотек.
Memory Allocation і Deallocatio: С / C++ / Rust використовують підходи, які ґрунтуються на ручному або напівручному управлінні пам’яттю. В Rust тут є перевага, оскільки в нього використовується напівручний підхід, що зменшує можливість виникнення проблем, а сам компілятор робить дуже багато перевірок, щоб забезпечити правильний час життя об’єктів.
Modern Features: у Rust чи не найбільша кількість нових підходів, які були описані 10 років тому і які не використовувалися. Ownership model, pattern matching, etc — все це робить програми на Rust більш лаконічними та безпечними, не втрачаючи у швидкодії.
Ecosystem: C та C++ вже мають великі та встановлені екосистеми, тоді як у Rust росте та розширюється, але мова ще не досягла такого рівня.
Порівняння С / C++ / Rust
У таблиці нижче можна побачити порівняння мов програмування C / C++ / Rust для ІоТ- проєктів.

Враховуючи всі ці фактори, можна визначити, що Rust виявляється конкурентоспроможним в певних аспектах та готовим до поширення, зокрема в області вбудованих систем та розробки нових продуктів. Також система збірки й інфраструктура в Rust рівня God дає значні переваги для початку нових проєктів. А екосистема, яка постійно розвивається, надає все більше і більше якісних бібліотек, фреймворків для роботи з проєктами різної складності.
Що пропонує екосистема Rust для IoT-проєктів
Екосистема Rust пропонує трохи обмежену кількість проєктів, фреймворків та операційних систем, порівняно з мовами програмування. Однак навіть за цього обмеження існують реальні продукти та інструменти, які використовуються і досить успішно. Зазвичай це охоплює вбудовані системи, розробку програмного забезпечення з високими вимогами до безпеки, а також інші сфери, де Rust може виявитися корисним.
TOCKOS
Першим таким проєктом є операційна система TOCKOS — вбудована операційна система з підтримкою чипів Cortex-M. Вона має стабільну підтримку для Raspberry Pi, STM, NRF, та ESP. Підтримка для ESP наразі не є стабільною, але над цим працюють. Цей продукт повністю написаний на Rust.
Це real-time операційна система, яка має свій Kernel, Scheduler та свою модульну систему. Щодо User Space, TOCKOS підтримує всі програми, написані на C і Rust. Це означає, що використання бібліотек та динамічних бібліотек з C також можливе. Документація є доброю, надає приклади для різних чипів і зручна для початку роботи.

Однак недолік полягає в обмеженій підтримці девайсів та чипів, але розробники працюють над цим. Це відкритий проєкт, і його код доступний на GitHub. TOCKOS має добрий інструментарій, який можна встановити через Cargo, включаючи флешери та дебагери.
Riot
Це операційна система для IoT, написана на C. Однак це популярна операційна система та фреймворк, спеціально призначений для IoT, з підтримкою різних протоколів, таких як MQTT, TCP, QUIC, LoRaWAN, Bluetooth, Wi-Fi тощо. Riot надає нативну підтримку для різних мікроконтролерів, зокрема восьмибітні.

Однією з переваг і важливим кроком є введення підтримки Rust. Можна писати application, використовуючи Rust, але якщо глянути в їхню документацію, там скоріше можна розгубитися як це робити, ніж зрозуміти. Однак це свідчить про те, що Riot розглядає варіанти використання Rust для розробки програм і це позитивний крок для майбутнього. Riot є добре документованою, навіть краще, ніж TOCKOS, і має ефективний інструментарій, зокрема підтримка Cargo.
Embassy
Це не операційна система, а фреймворк для IoT, який має свій асинхронний екзекутор. Його основна перевага полягає в тому, що він дозволяє працювати в асинхронному режимі, що спрощує написання функцій за допомогою async / await. Фреймворк володіє власним планувальником задач і підтримує широкий спектр тасок.

Embassy надає більшу підтримку платформ, порівняно з TOCKOS, охоплюючи Terascale Pi, STM, NRF, ISP та інші, які можуть бути додані або вже підтримуються. Основна частина їхнього ядра написана на Rust, і вони надають підтримку мережевого стека, Bluetooth та різних протоколів для IoT.
Цей фреймворк дозволяє писати застосунки на Rust і вражає своєю модульністю, докладною документацією та ефективним інструментарієм. Проєкти, пов’язані з Rust, взагалі славляться хорошою документацією, використовуючи
Інші проєкти та фреймворки в екосистемі Rust

Наприклад, Hardware Abstraction Layer (HAL), який має цілий репозиторій на GitHub і описує абстракцію апаратної частини для Rust, призначений для використання на різних платформах.
Ще одним прикладом є AWS IoT Core, яка пропонує екосистему для IoT як сервіс. У них є SDK для Rust, що дозволяє писати застосунки для мікроконтролерів за допомогою Rust, працюючи з їхніми протоколами.
Eva — це інший фреймворк для IoT, який надає підтримку різних протоколів та дозволяє писати застосунки на Rust.
Також існують менш популярні бібліотеки та протоколи, які можна знайти на Create.io, такі як бібліотеки для LoRaWAN, MQTT, Quic, LWM2M, CoAP, а також для забезпечення безпеки, Bluetooth, Wi-Fi та інших IoT протоколів.
Хоча деякі з цих бібліотек можуть бути менш мачурними, вони постійно розвиваються, і зі зростанням попиту буде йти пропозиція нових та кращих рішень в цьому напрямку.
Висновок
Отже, Rust є хорошим вибором для IoT та Embedded-проєктів. Мова забезпечує безпеку на рівні типів і допомагає уникати null-pointers, а також немає undefined behavior. Для більш складних проєктів важлива підтримка конкурентності та можливість використовувати багатозадачний режим, і Rust забезпечує цю можливість.
Для успіху мови важливо, щоб екосистема продовжувала зростати та наповнюватися різними бібліотеками та фреймворками. Підтримка великими компаніями, як-от Microsoft та Google, також говорить про потенціал мови. Попри всі переваги, Rust усе ще має недоліки: зрілість екосистеми, високий поріг входу, різноманіття тулінгу.
Rust відрізняється універсальністю, підтримкою різних сфер, зокрема Embedded, Game Development та Backend Development. Хоча Rust може бути повільнішим у розробці порівняно з іншими мовами, він компенсує це безпекою, продуктивністю та зручністю інструментів.
Приклад з практики
Я створив невеликий проєкт під ESP32, який з першого погляду досить примітивний, але водночас є доволі показовим у тому, як легко створити та розгорнути проєкт для проведення PoC, щоб показати клієнту або перевірити гіпотезу.
Існує хороший гайд з того, як почати проєкт під чипи ESP32.
Перше, що нам знадобиться, це встановити Rust.
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Після цього потрібно встановити генератор шаблонів для cargo.
cargo install cargo-generate
ESP мають власні шаблони проєктів, якими можна скористатися. Є шаблони і під використання std, і no-std.
Згенеруймо проєкт з використанням std.
cargo generate esp-rs/esp-idf-template
Сам генератор є доволі інтерактивним і, крім імені проєкту, дозволяє вибрати такі опції:
- MCU target — чип, під який буде писати прошивка;
- версію ESP-IDF бібліотеки;
- std or no-std;
- використання Dev Containers — дуже зручний механізм, який дозволяє розробляти програму в докер-контейнері, де вже буде встановлено всі необхідні програми. Добре використовувати в поєднанні VS Code. Оскільки це дозволяє просто відкрити папку проєкту і займатися розробкою, не переймаючись за встановлені бібліотеки чи програми;
- використання Wokwi симулятора — це програма, яка дозволяє симулювати роботу з різними мікроконтролерами, а також периферією, яку можна під’єднати до цих мікроконтролерів. Дуже зручно для тих, хто ще немає реального девайса.
Після того, як генератор згенерує проєкт, його структуру буде виглядати так:

Ця структура повністю дозволяє займатися програмування і не перейматися інфраструктурою, оскільки вона вже тут розгорнута.
- В папці
scriptsє необхідні скрипти для того, щоб зібрати проєкт і залити його на реальний девайс. wokwi.tomlтаdiagram.json— конфігураційні файли, які дозволяють запустити симулятор. Потрібна ліцензія для симулятора, вона безплатна й можна отримати тут.
Створімо доволі простий проєкт з Hello World, Rust & Yalantis. Насправді цей приклад був взяти з сайту Wokwi та служить для показу можливостей Rust і екосистеми.

Я не буду розписувати весь код для роботи з lcd, а покажу тільки main.rs, де виконується вся логіка.
use esp_idf_hal::i2c::*;
use esp_idf_hal::prelude::*;
use esp_idf_hal::delay::FreeRtos;
use esp_idf_hal::peripherals::Peripherals;
mod lcd;
fn main() -> anyhow::Result<()> {
let peripherals = Peripherals::take().unwrap();
let i2c = peripherals.i2c0;
let sda = peripherals.pins.gpio6;
let scl = peripherals.pins.gpio5;
let config = I2cConfig::new().baudrate(100.kHz().into());
let mut i2c = I2cDriver::new(i2c, sda, scl, &config)?;
let _ = lcd::init(&mut i2c);
let _ = lcd::backlight(&mut i2c);
let _ = lcd::set_cursor(&mut i2c, 0, 1);
let _ = lcd::print_str(&mut i2c, " Hello, World");
let _ = lcd::set_cursor(&mut i2c, 0, 2);
let _ = lcd::print_str(&mut i2c, " Rust & Yalantis");
loop {
for _ in 0..3 {
lcd::scroll_left(&mut i2c);
FreeRtos::delay_ms(100);
}
for _ in 0..2 {
for _ in 0..6 {
lcd::scroll_right(&mut i2c);
FreeRtos::delay_ms(100);
}
for _ in 0..6 {
lcd::scroll_left(&mut i2c);
FreeRtos::delay_ms(100);
}
}
for _ in 0..3 {
lcd::scroll_right(&mut i2c);
FreeRtos::delay_ms(100);
}
for _ in 0..3 {
lcd::no_backlight(&mut i2c);
FreeRtos::delay_ms(250);
lcd::backlight(&mut i2c);
FreeRtos::delay_ms(250);
}
}
}
Код програми доволі простий, вона виводить на lcd вказаний текст і рухає ним по lcd з періодичністю у 100 мс.
Після цього ми можемо зібрати проєкт:
cargo build
І налаштувати шлях до бінарного файлу в wokwi.toml
[wokwi] version = 1 gdbServerPort = 3333 elf = "target/riscv32imc-esp-espidf/debug/example" firmware = "target/riscv32imc-esp-espidf/debug/example"
І кліпнувши на diagram.json запустити симулятор. Симулятор автоматично візьме firmware з вказаного місця і запустить проєкт, наче він раниться на реальному пристрої.

Це все, що робить приклад, але набагато важливіше, які можливості надає ця інфраструктура і Rust для розробки прототипів та їхнього налагодження. Wokwi також дає можливість запускати програму в режимі debug і налагоджувати програму.
FAQ
Які підходи до налагодження та тестування застосовуються при розробці IoT-застосунків на Rust, подібні до тих, що використовуються в C++?
У Rust, подібно до C++, налагодження передбачає використання дебагера, який підмикається до більшості пристроїв і допомагає налагоджувати їхню роботу. Ви можете завантажити код, встановлювати точки зупинки та запускати дебагер для аналізу виконання коду. Rust забезпечує цей підхід за допомогою свого інструментарію, зокрема GDB та інші дебаг-інструменти.
Як можна зменшити енергоспоживання IoT-пристроїв, використовуючи Rust?
Зменшення споживання енергії в ІоТ-пристроях залежить не тільки від вибору мови програмування, але і від вибору стратегії розробки. Зазвичай краще використовувати підхід з операційною системою реального часу та використовувати suspend mode, sleep mode.
Пристрій буде більшість часу в сплячому режимі та час від часу прокидатися і передавати дані. Rust, завдяки своїм можливостям системного програмування, а також безпеці, може бути корисним, але основна роль відводиться підходу до виконання задачі.
Які аспекти управління пам’яттю слід враховувати під час розробки IoT-пристроїв?
ІоТ-пристрої — це часто пристрої з обмеженою кількістю пам’яті. Rust завдяки своїм парадигмам до роботи з пам’яттю (ownership, lifetimes, etc) дозволяє найбільш ефективно її використовувати. Також завдяки строгим правилам мови зловити memory leaks і undefined behavior неможливо, від чого використання ресурсів буде найбільш ефективним.
З чого розпочати тим, хто ніколи не писав під IoT?
Рекомендується почати з використання симулятора. Спочатку зосередьтеся на засвоєнні основ вбудованих систем і спробуйте реалізувати прості проєкти. Поступово переходьте до реальних пристроїв, придбавши доступні набори, як-от Arduino, і переходьте до більш складних пристроїв залежно від набуття навичок і розуміння.
71 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарівбаг дитекдед:
на на гую виводиться
не як експектід
Про всяк випадок поясню, щоб не було зайвих питань. Concurrency Support має бути в голові у інженера, саме він має приймати рішення що до розподілу доступу до ресурсу, відповідно до бізнес-логіки, обираючи найбільш підходячу (іноді многорівневу та комплексну) стратегію, використовуючи при цьому комбінації з різних підходів, таких, як відмова блокування (брудний доступ), атомарний доступ, бар’єрне виконання, монітор ексклюзивності, контроль переривань та їх пріоритети, спін лок, засоби операційної системи, такі як м’ютекси, івенти та інщі об’екти, кастомні рішення. Яким чином це стосується мови програмування — мені не дуже зрозуміло
язык программирования может дать гарантии, что большинство ваших конструкций в области многопоточного программирования будут корректно сформулированы и не уводить в зону UB
ти ще скажи шо кодити треба в блокноті без підсвітки синтаксісу і всяких clangd.
бо весь проект має бути в інженера в голові.
Євген я тільки частково з Вами погоджуюся, вже не той час коли треба було тримати все в голові і С++ був не поганий не через те, що є пробіли в дизайні мови, а просто через, те що не осилили. В цілому навіть ті ж самі плюси показують , що рухаються вони у сторону більшої визначеності та безпеки. Тобто коли ціна помилки програміста не буде коштувати мільйони доларів. Всі ми люди і всі ми робоми помилки. В цілому більшість проектів це не рокет сайнс і безпека і визначеність приносять більше користі для бізнесу. Саме тому інші мови популярніші за С++ чи С.
Мова не йде про те, щоб тримати у голові проект, а про те, щоб тримати перелік наявних підходів та засобів і розуміти де та коли їх використовувати. Це те, що складно або не можливо формалізувати і саме у цьому і полягає інженерна робота
і паралелизм багатопроцесорності з мультипоточністю
Я вивчаю програмування з 1991, починав з PDP-11, компи були УКНЦ під ОС RT-11. Поясніть мені, будь ласка, що таке Memory Safety, Concurrency Support та Safety Guarantees)
Наразі у нас на всіх Embedded-проектах C++11/14/17/20. Як на мене, Rust — це щось не потрібне, створене для розв’язання штучних проблем. Коротше, плюси рулять!
Це просто гарантія від компілятора, що в safe коді немає race conditions, немає memory leak та невірних операцій з пам’яттю. Тобто узяти ітератор, потім додати елемент у контейнер, а потім звернутися до ітератору тобі просто не дасть компілятор.
а нашо тобі ті плюси?
ти ж такий талановитий і все тримаєш в голові. пиши на асемблері.
а то ти диви, якісь смартпоінтери, якісь GSL, якісь незрозумілі обгортки над системними потоками і мютексами. Якесь RTTI і віртуальні функції.
нашо тобі отой весь мусор?
С++ взагалі не всіх проектах є які відносяться до embedded, умовні STM в переважній більшості програмують під С.
Цього я взагалі не зрозумів. Тобто нам всім потрібно перестати розвиватися, бо колись було більш лампово?
тут я нічого не зрозумів, чи не могли б ви переформулювти
— поясняю. За цей довгий час я багато разів бачив, як змінюються парадигми, концепти, пріоритети, маркетингові трюки та інші модні слова)
якщо в авто є пасок безпеки, то для мене він завжди залиштеся просто паском безпеки, а не елементом інтегрованої системи безпеки пасажира, до складу якої, наприклад, також входить модем ecall. Це не тому, що я зупинився у розвитку, це тому, що багато речей для мене сформувалися досить давно і я трохи по іншому дивлюся «новітні» технології до складу яких входять ці речі
черговий «ідущій до річки» плюсовік який вже все поняв про цей світ.
З одного боку не розуміє які проблеми вирішує раст а з іншого боку не може пояснити якіж такі проблеми вирішує С++.
То які проблеми вирішив С++ і шо він рулить?
Наратив і скепсис до псевдо-новітніх технологій зрозумілий, але я переконаний, що ви все таки хибно відносите Rust до цього переліку. Як на мене, властивості расту як мови дійсно якісно відрізняються від інших, зокрема через дуже розумне і вдале застосування математичного апарату з теоркату для вирішення конкретних практичних проблем з memory safety, concurrency і дизайну мови взагалі, не кажучи вже про цілу купу приємних дрібниць.
Є купа евангелістських матеріалів з розвісистими прикладами і поясненнями, але тут треба руцями пощупати. Спробуйте, вам сподобається. Я, буквально, не знаю жодної людини, яка б спробувала і не сподобалось.
Как минимум сравнение с C и C++ выглядит очень странно.
Почему RAII это «полуручное» управление памятью? И с чего вдруг у Rust тут есть какое-то преимущество перед C++?
Почему в C нет concurrency? Есть стандарт C11 threads, есть де факто стандрат (pthreads), а в случае всяких embedded RTOS это обычное дело, что используешь какой-то местный API для многозадачности.
Тоже самое зачем-то написано про C++ «може вимагати додаткових зусиль та використання бібліотек».
Приведенный код, как по мне, реально уродливый
let _ = lcd::init(&mut i2c);
let _ = lcd::set_cursor(&mut i2c, 0, 1);
let _ = lcd::print_str(&mut i2c, " Hello, World");
На хрена эти let _? Передача i2c на каждый чих?
Создаешь себе экзепляр класса и пользуешься:
Lcd lcd(i2c);
lcd.set_cursor(0, 1);
lcd.print_str(" Hello, World");
Тому, що, наприклад, C++ ніяк не вирішує проблеми з memory aliasing. Використання смартпоінтерів ніяк не убезпечує від вистрілів в ногу.
Банально, два unique_ptr, всупереч семантиці, цілком можуть містити один і той же поінтер
std::unique_ptr<int> ptr1(new int(42)); std::unique_ptr<int> ptr2(ptr1.get());Внутрішній поінтер можна без проблем витягти і винести за скоуп лайфтайму смартпоінтера.
{ std::unique_ptr<int> ptr(new int(42)); return ptr.get(); }Move насправді не робить мув, оригінальний об’єкт нікуди не зникає:
std::unique_ptr<int> originalPtr(new int(42)); std::unique_ptr<int> newPtr = std::move(originalPtr); std::cout << *originalPtr;Ну або ж взагалі класичний сішний приклад з aliasing в strcpy, проблеми якого в С++ ніяк не вирішуються.
В Rust аналогічні спроби ведуть до помилки компіляції, через три фундаментальні концепції: ownership, borrowing, lifetime. Навіть в unsafe коді вони нікуди не діваються і все ще присутні.
смешались в кучу кони-люди...
там вообще отдельным пунктом идет «Memory Safety» и отдельно «Memory Allocation і Deallocation»
в контексте последнего пункта в чем я не прав?
А ще за 2023 рік аж 51 вакансія на Rust — найменше серед усіх мов програмування, що були в рейтингу dou. Для порівняння, С++ має 718 вакансій.
Це питання тільки часу. С++ уже на ринку існує більше 30 років. Rust доволі молодий, і все більше часто появляються новини що великі гравці починають його адоптити у своїх проектах.
Воно-то так, але як замовнику продати Rust, якщо на нього важко знайти людей? Або якщо людина вивчила Rust, то як їй знайти проєкт? Як на мене, то це все ще досі дуже нішеве та експериментальне. Якщо хочеш ризикнути — береш Rust, якщо хочеш впевнено та надійно — C++.
якшо брати саме baremetal embeded, то тут король С.
а С++ так само як і Раст тільки бореться за нішу і не має ніяких переваг (бібліотеки, спеціалісти, довіра замовника)
Всяко буває. Ми на С++ писали бутлоадер (baremetal з викликом переривань BIOS в16-бітному режимі). Звісно, це обмежена версія С++, але все одно краще за чистий С. Компілятор один і той самий, то чому відмовлятися від додаткових можливостей.
Мне не ясна причина Вашего перехода на rust, в статье указано: «До цього я мав пʼять років досвіду роботи Embedded Engineer з використанням C/C++.»,
то есть 5 лет опыта в C/C++, и Вы сами понимаете, что rust в данном случае это всего лишь обёртка, то есть он делает всё то же самое что и C/C++, С#, и большая часть кода и библиотек на них уже есть, и те кто имеет большой опыт в этих языках, они не хотят менять шило на мыло, и у Вас уже есть кодовая база, но Вы стали rust евангелистом при этом, какова причина такого перехода?
Все дуже просто, мова більш приємна у застосуванні, більше можливостей концентруватися на бізнес проблемі, а не на проблемі мови, проекти без 20 літнього легасі, яке ти тупо підтримуєш. Більш зручний package manager. С++ за ці роки так і не змогли якийсь стандарт принести в мову. Досі подобається С++, але на расті я можу написати те що мені треба швидше, буде більш лаконічно виглядати і при цьому не буде UB.
Головне не побачили (на таблиці з порівняння мов програмування): Toolchain + Rust = God! <3
ви джинні дивилися?
Ні, на dou. На джинні зараз так: Rust: 10, С++: 197.
на доу 47
jobs.dou.ua/vacancies/?category=C+
джині хз, там фільтр по зепе, але не думаю, що 718
То статистика за весь рік: dou.ua/...les/jobs-and-trends-2023
-40% відносно 2022
а претендентів?
невідомо
отож, як же тоді «попит-пропозиція»?
з.і.
по ембедед є ріст відгуків на вакансію з 4.4 до 4.7
з.з.і.
на віддалено легше знайти на Rust, IMHO
Я не знаю цифр по попит-пропозиції. Але на Rust дуже мало вакансій, тому всі показники нестабільні. Якщо умовно +10 людей захочуть перейти на Rust — вони одразу змінять ринок.
локальний? можливо,
тільки в нас аутсорс, це глобальний,
а там взаємореакція: мало вакансій бо мало розробників, і тому мало вакансій.
тільки тру С++ не зраджують заради іржавого, бо КОБОЛ
Це дуже хороша стаття для своєї цільової аудиторії. Автору подяка за даний огляд та підтримання розвитку Rust спільноти!
Не згадано про мабуть найбільший недолік Rust — надмірну ширину ідіоматичного спектру.
Так само як під «C/C++» можно розуміти як K&R C, так і С++20, з зовсім різними best practices і прийнятими на окремих проектах застосовуваними підмножинами мови, так само і між Rust core і звичайним Rust на якому пишуть блокчейни — це фактично різні мови з невзаємозамінними спеціалістами, при цьому сore ще навіть не має офіційного релізного статусу. Так що принаймні у ніші С для мікроконтролерів, написання нутрощів ОС і драйверів, системного програмування, переваги Rust зовсім не очевидні, і скоріше за все він замість них буде фокусуватись на все більш високорівневе програмування, як свого часу Pascal був потіснений C, C++ і Objective-C з написання ОС, але у вигляді Delphi/Lazarus досі місцями живий для апок.
але Rust таки додали як другу мову в ядро Linux.
є купа SDK/HAL для мікроконтроллерів.
є різні RTOS-и.
яб сказав що раст у ембеді вже на рівних з С++.
З.І. мови С/С++ немає
У якому сенсі і чому?
в тому сенсі що С і С++ це 2 окремі мови програмування.
А, та я невірно зрозумів написане, я це спросоння прочитав як «взагалі не існує їх, штучно вигадані мови»
Я їх завжди через крапку або кому пишу, а не через слеш-дефіс
Окремі, але дуже споріднені. Я в одному проєкті можу мати *.c та *.cpp файли, і все буде працювати «з коробки». Також, 99% С кода є валідним C++ кодом.
звісно С і С++ споріднені, але то 2 окремі мови.
а я в одному проєкті маю *.c & *.rs, і в мене теж все працює.
дуже сміливе твердження про 99%
Не в ядро, а для модулів ядра, і, наскільки я знаю, у мейнлайні немає ще жодного модулю на ній.
Про це і пост — Rust теж немає, є окремий ідіоматичний юзерспейсний Rust, і Rust-core, і це гарантує проблеми з наймом спеціалістів.
а, ти з тих хто починає крутитись на сковорідці і придумувути свої странні визначення загальноприйнятим явищам?
а деж по твоєму знаходяться модулі ядра в монолітному ядрі?
і шо сталось з твоім твердженням
?
а ото твоє
то до філософів, то вони полюбляють пофантазувати чи написана програма на С++ якшо ти використав printf а не std::cout. I тому подібну чухню. чи то одна мова чи 2 якщо я не використав в програмі Vec.
Rust — не загальноприйнятний.
А де? Вам знайома різниця між mainline і out-of-tree модулями?
Один раз доведеться прикрутити ручками той плюсовий рантайм у початково pure C середовище від вендора, з хіпом і ексепшнами, бо комусь закортіло гарного коду, і розуміння різниці відразу з’явиться.
скок-скок, то де ж ті модулі ядра в моноліті?
а ти спробуй відповідати про те шо питають.
чи в тебе з цим важко?
Це Rust робить розробників настільки агресивними?
Уті-путі.
Сергійко прийшов накинути гівнеця, але обляпався сам.
І замість того шоб або довести свої тези або вибачитись розігрує карту ображеного.
Embedded це специфічний домен, будь яка загальна мова програмування окрім самої мови потребує знання домену. Перевага Раст в цьому випадку в тому що компілятор бере на себе відповідальність забезпечуючи безпечну роботу з пам’яттю.
rust::core version 1.74.1 — що мається на увазі що не має релізного статусу?
Please note that all of these details are currently not considered stable.
і шо?
типу С стабільний?
стандарту С для embedded теж немає. всі фічі нестабільні і залежать як від вендора компідятора так і від версії.
Так, С стабільний. У нього стабільний ABI, стабільні, задекларовані у стандартах фічі мови, а будь-які навіть стандартні ліби — таки ліби, які прозоро можна (не)підключати.
Свої відступлення у вендорів певних компіляторів звісно є, але їх використання у продакшні скоріше виключення, ніж правило.
це показує шо ти тупо балабол а не розробник який шось хочаб чув про про розробку.
все равно у тебя есть какой-то порог вхождения и чем больше проект, тем он выше
поэтому это вряд ли тот фактор, что не даст Rust войти в эту нишу
таке можна сказати і «про С++, що метапрограмування і С++ як С з классами, це фактично різні мови»
Так це ж правда, ідіоматичний код між С11 вже досить сильно відрізняється від підмножини типового С++20, і непогано було б це вказувати в вакансіях і компонентах явно, а не ліпити оте «С/С++».
10 років назад так само називали Rust «вбивцею» C++. Наразі виглядає все так само...
Rust і не претендує на цю посаду. Скоріш він просто з часом займе свою нішу в embedded і буде як третя мова, але про повну заміну в ближчі років 10 думаю не варто говорити.
Щоб зайняти нішу в embedded, треба з неї видавити Сі. А це буде досить важко.
навіщо видавляти?
с++ знайшло,
так і руст знайде (напр.як для ардуіно з плюсами)
Якщо брати Linux Kernel, то С++ там не дуже багато. А так... при бажанні можна хоч на Delphi писати, але то більше академічність.
але це не точно, точніше 0.0(0), і найближчим часом більше не передбачається,
а от з Rust трохи інакше.
Ну... в принципі, ніхто не заважає тобі використовувати С++ для написання власних модулів ядра. Наприклад, я бачив код модуля, де використовувалися С++ шаблони.
Приблизно така сама ситуація і з Rust, з єдиним виключенням. Щоб писати на C++ власні модулі, тобі в принципі нічого і не потрібно, працює із коробки. А щоб писати на Rust треба деякий адаптер, який і був залитий.
Ну а С++ не використовується часто при написанні власних модулів з іншої причини: самі розробники цього не дуже хочуть, бо не бачать великих переваг.
Так, names mangling і все таке, що писати на С++ в С стилі, дійсно переваг небагато
olegkutkov.me/...1/10/cpp-in-linux-kernel
Ви так пишете, що можна подумати, що це якась жахлива проблема. В принципі це усім відомо, виникає на проектах, то використовується разом сішний та C++ код, наприклад у бібліотеках, які дають сішний інтерфейс, а нам ним при бажанні C++ надбудову з класами.
Той кейз, що я описав, перевага була. Бо шаблони на Сі це або копіпаста, або магія с препроцесором, коли один і той же сирцевий файл компілюється з різними дефайнами. Чому тоді не С++?
Ну а так проблема більше у тому, що не працює з коробки більшість існуючих С++ бібліотек, наприклад STL. Не кажучи про те, що STL та контейнерно орієнтована розробка з володарем не дуже лягає не концепцію ядра Linux, усі неявні realloc важко відстежити. Rust у цьому плані хоч це перевіряє.
Але ситуація з Rust бачиться мені наступна: пройшли люди програмувати ядро, і це було настільки важко для них, що сказали вони: «От тільки Rust може вирішити ці проблеми». ОК, зробили для них Rust. Хвиля спала, вони переконалися, що Rust не дуже й допомагає, та пішли з ембеддед з почуттям виконаної справи, що їх Rust вже в ядрі.
не можу сказати, які сексуальні проблеми їм мав вирішити раст, свічку не тримав, але якщо людям подобається
трахмагія з дебагом, то медицина тут безсильнасаме так і було, інфа 146%
Цікава точка зору, але в чому «ніша», і чому за 10 років не знайшлося...
C++ буде з часом як Кобол
Перший мій коментар на доу за років 7, але це якась маячня а не стаття) Працюю з Iot вже 10 років. З растом не стикався, думав може дізнаюсь щось цікаве, а тут якусь доку з esp та купу непов’язаного змістом, а лише темою матеріалів. Наче студент 3чник реферат з інтернету наскидав. Н-да
Шкода що Вам не сподобалося, можна глянути івент де я розповідав про цей топік і як можна використовувати Rust. www.youtube.com/watch?v=64Q8UOtFitY
головне камєнти,
зі:
ІоТ більше про клауд, а тут навіть не про едж