[delayed]

In C++, you'll often see projects just use boost, which is a big monolith of useful libraries.

Embedded microcontrollers are not the place where boost is used.

Counterpoint: I use Boost on embedded microcontrollers. (Albeit only header-only components of Boost.)

I suppose that wasn’t clear. My mistake. I use C/C++ for micro controller code every day, because Rust doesn’t support my microcontroller, doesn’t have a real RTOS, and I’m making real hardware. Something that needs to run in the field for 10+ years and I can’t get out there and ensure it’s updated, and my company doesn’t want to invest millions of dollars on beta testing embedded rust on. So embedded is out for now but I’m looking forward to when it’s supported fully and out of beta. Most embedded controllers come with some RTOS and libraries they support, written in C.

For tooling, I can context switch out of C++ which does have boost, into [rust, go, python… etc] and deal with that switch, or just be lazy and write it in C++. I’ve tried to write three tools in Rust so far, and the pain of not having a good stdlib, of essentially searching the internet for a blog post that solves my issue then finding the blog post was written by one dev 4 years ago to pump up their library that was written 4 years ago and then never supported after that… it’s a bit exhausting.

Again, before ya’ll attack. This is from the perspective of a willing, excited customer. I want to use Rust at work and advocate for it. Just saying, it’s not easy in the state it’s in.

Which microcontroller are you using? Rust support for embedded targets is slowly improving, so there might be a beta build for your chip.

ESP-32, the Rust support is not mature enough to ship commercially.

C-410 from Qualcomm, which is a whole different world, I can’t even look at the source code.

I'm sympathetic. I'm partway into an embedded project on an stm32 / m0 for which there _is_ good rust support through Embassy and it's utterly magical. And at the same time, trying to do something for which there isn't a good no-std crate is, er, anti-magical to the point of forcing me to change the design. The ecosystem isn't as comprehensive yet.

But when it works, wow. This has been the most fun embedded project I've ever done with the least debugging.

I have replaced my use of C (and C++) in embedded with Rust for the last couple of years. Sure, some parts are still missing or immature, but overall also very promising. And I do enjoy it so much more than the MCU manufacturer's please-insert-your-c-code-between-these-comments-and-pray kind of development.

Are you doing this on personal projects or commercial projects? I'm pretty happy with c++17 on all my embedded commercial projects

Strictly commercial. But if one is happy with other language I guess there is little reason to switch.

The people behind the esp32 are writing a rust compiler.... I have played with it only a little, but it worked

Edit:spelling

A full rust compiler instead of use the "de facto" one? on a language as complicated as rust that sounds scary unless they have a lot of financial backing and significant amount of compiler devs.

Why would they not just adapt the code generator for the reference compiler? Rust is a moving target, committing to a new compiler at this point is a massive investment.

Not a rust compiler, they provide crates to interface with their C code in ESP-IDF, which is essentially a FreeRTOS port that supports the dual core Espressif chips, which vanilla FreeRTOS does not support. Also some of their own libraries for things like MQTT, which I found unfortunately subpar in comparison to the vanilla FreeRTOS code.

It’s all beta software, but here is what they list in the docs:

Services like Wi-Fi, HTTP client/server, MQTT, OTA updates, logging etc. are exposed via Espressif's open source IoT Development Framework, ESP-IDF. It is mostly written in C and as such is exposed to Rust in the canonical split crate style:

a sys crate to provide the actual unsafe bindings (esp-idf-sys) a higher level crate offering safe and comfortable Rust abstractions (esp-idf-svc) The final piece of the puzzle is low-level hardware access, which is again provided in a split fashion:

esp-idf-hal implements the hardware-independent embedded-hal traits like analog/digital conversion, digital I/O pins, or SPI communication - as the name suggests, it also uses ESP-IDF as a foundation if direct register manipulation is required, esp32c3 provides the peripheral access crate generated by svd2rust. More information is available in the ecosystem chapter of The Rust on ESP Book.