One of the author's here, if there are any questions!
Yeah of course. Then again - they were one person teams, where the C "team" had years of experience in stm32 / embedded C / stm32 cube development and churned out that handwritten state machine in just days. The Rust "team" was a pre-masters intern with only minimal embedded Rust experience. They ran into all the pitfalls with (async) embedded Rust, but corrected towards the end.
I do applaud you for having the same work done twice but it would have been far more meaningful to have two actual teams of seasoned developers do this sort of thing side-by-side. The biggest item on the checklist would be the number of undiscovered UB or UB related bugs in the C codebase and to compare that with the Rust codebase on 'defect escape rate' or some other meaningful metric.
I've got my own set of restrictions for when I'm coding in C based on many nights spent poring over various pieces of code and trying to find a way to do it better and safer without outright switching languages. I do believe it is possible. But at the end of all that you have essentially redefined the language in a way that probably no other C programmer would like or agree with, and it would still require very good discipline.
So having languages with fewer footguns is good, as long as the lack of one kind of footgun isn't replaced by a other kinds of footguns. It is one of the reasons I'm interested in the FIL-C project.
My personal view is that good C code looks a lot like Rust where ownership is clear and a borrow checker would approve. The mindset that Rust forces you into is the same one you should be using when writing C.
The longer-term concern is that, if you’re spending late nights learning Rust, it’s probably with the borrow checker. Late nights with C, it’s probably with memory management. One of those two is a bit more applicable to understanding computing at a deeper level.
I mean sometimes efficiency matters a lot, but a lot of other times, interoperability is more important.
Text based IO with microcontrollers over tty has been quite a standard thing even decades ago.
> The command-response protocol and binary data format are described in device models generated using DTDLv2 [10], a JSON-based language for describing digital twins. These models are used within the Azure IoT Plug and Play (PnP) framework [11], which STAIoTCraft adopts for datalogging
I’d guess that’s an area where C tooling is pretty far ahead of Rust tooling at present?
2. Well, ST has released official Rust drivers for a bunch of their sensors. They're built on embedded-hal(-async), so can directly be used with Ariel OS. There is probably more.
"Author's" is possessive; "authors" is plural.