Thank you for sharing your thoughts!

I started to look at Rust a couple of years ago. First, because I wanted to put something beside C/C++ in my pocket, and second, because of the hype. All that fuss about the "fast, reliable, safe super-language of the future", you know. :-) In the end, it became my "weekend toy" for PC. Write a little project here, a piece of code there, become surprised things are not going the way they go in the venerable C. That sort of stuff.

Personally, I don't think Rust will overrun the C/C++ in the deeply embedded application. Ones, where programmer deals with the registers and memories directly and where it is the most natural way to get the job done. Just because these are inherently unsafe operations, which Rust tries to prevent. Trying to write code in the "Rust way" simply makes it more verbose and harder to understand, while some special "crates" aimed to mitigate Rust's restrictions or numerous "unsafe" sections will simply break the philosophy of the language. What's the point of using the "safe" language in the "unsafe" way, right?

At first glance, it seems to be full of useful features, and some of them really are (modules/namespaces, "impl" blocks for structures) etc. While others, in the end, rendered to be confusing and questionable. For instance, the enumerations, which cannot be easily cast to integers. Or strings, which are UTF-8 encoded, and there are some peculiarities when indexing them. Maybe the GUI-reach applications really need the fancy encoding, but a debug console/terminal, where just the first half of the ASCII table is used, definitely does not. And many, many others. Maybe it is my C bias, and I just need to think in the "Rust way", but sometimes it ticks off.

And some features, if scrutinized, become a significant problem. Another example is the "crate" concept. It is very convenient when you don't need to supply the compiler all those paths to header files, source files and so on. Just feed it the crate's root, and it will reach the very last module automatically using the naming convention. But what should I do if I'm running the unit tests and I want to substitute some dependencies with the mocks? Copy module to an auxiliary project to test it there? But what about the built-in testing support? I haven't found the answer to that question yet. Maybe it is buried somewhere deep in the "rustc" or "cargo" documentation and I just need to spend a few more hours (or days) searching. :-)

But don't get me wrong, I'm not telling it is a flawed language. It is definitely interesting, has its own advantages, and quite possibly will find its way into mainstream development, or at least a certain niece. But currently, it poses a challenge for a "classic" embedded programmer. Maybe that will change in the future. Or maybe it will decline like the Ada. That we will see.

Of course, that's just a humble opinion of a very regular developer. :-)

While I enjoy coding in Rust, from this video my impression is Rust support for microcontrollers is really only prime for STM32. My quick search for Rust on PIC16 and Arduino leads me to believe it wouldn't be worth the effort.

I think your explanation of a crate isn't quite right. A crate can contain multiple .rs files and is more similar to a library. Crates can contain multiple modules, which is closer to what you're explaining, where each .rs file is, by default, a single module (you can also define multiple modules in a single file if you'd like).