For me the problem with Rust has been mostly the documentation and specifically the auto generated API documentation. Nothing wrong with generating documentation from source code, but even the standard library seems to have a lot of methods that have just one line, actually only a shortened sentence, as a description. You are apparently supposed to recognize what this is about just from the name of the function and the function signature. This part is really subpar :-( The thing is for a learner you don't know how things fit together, plus parsing the signatures can be very hard. Double so if you are not used to read signatures with a lot of type variance, which might be concepts you do not really understand that well.
That is a big fail. Automatically generated documentation is outright useless because the coherency between the parts gets lost. How the parts fit together and how they are to be used is the most important information a user for a library needs. Someone should add ChatGPT to Doxygen as a code analysis tool and produce documentation. It will be an improvement for sure... But maybe (hopefully) there is a book about it.
This is absolutely my biggest sticking point with it too. The Rust Book is a pretty good introduction to a lot of the language concepts, but it has no
context. When I'm learning a new language I tend to spend most of my time in the library/API documentation sections poking around the bits I think will be useful to the problem I'm solving. Usually these docs will include context-aware usage examples which are idiomatic, and help with understanding how to compose useful things out of the language concepts. To me this is what is lacking most. Once you understand that so much behaviour is driven by Traits, you learn to follow the trail of Trait implementations to find some documentation on how they're meant to be used, but again, these docs & examples lack the context of the struct implementing them, which doesn't help much with idiomatic usage of a given library. Not to even get into how difficult it is to make sense of what the type generics are being used to do. Huge room for improvement here, especially (obviously) with embedded that is much newer in the ecosystem.
That's not what most of the posts I've read or written here are about. If that's what you read, read again. IMHO.
The thread at large, no, but the chain of posts I was referring to was a lot of 'I want to do <thing I can do in C> in Rust and it sounds like I can't'. In general, any comparison or 'subjective' evaluation may not explicitly be with respect to C, but it's a pretty darn safe assumption in this space. Whether or not that's the case in the thread, the point was to bring some things folks might/probably not know about if they haven't looked at Rust past the surface, which I haven't seen a lot of discussion about.
Unfortunately, we are failing to see any real-world metric that would prove it yields undoubtedly "safer" products while keeping productivity at a reasonable level, so it's often a lot of talk and some whining as soon as some people dare question its benefits.
If I'm mischaracterizing the conversation, I think this is doing the same. My main point is not even about safety, despite that people seem to think this is all Rust has to offer. Whether or not this leads to fundamentally safer products in the end is not really an answerable question. There's a) far more to it than thread/memory safety and b) other ways to prove/test/guarantee the system is working properly (though these are generally a lot more expensive than a few seconds of compile time). But when I'm wearing my developer hat, I certainly appreciate having two fewer things that can be fraught with hidden pitfalls to think about, and which I will certainly get wrong eventually, no matter how good I think I understand what I'm doing. Outside of embedded, which is still a
very open question for me, I have found it's just a pleasant and capable tool to use. It offers all the performance of other low-level languages, but far more modern niceties, most of which are 'free' at runtime, which for me makes it nearly as usable as something like Python.
Does that transfer to embedded without creating undue friction? Still trying to figure that out, but I don't think there is a way to know without getting your hands dirty and actually learning the language, because it is fundamentally so different. From what I've done so far, I think it is not ready yet, the HAL APIs aren't stable enough/have some warts, too much type ugliness shows through to the application, and as mentioned the documentation - but these are not
language issues and it seems things are improving rapidly. If you just want to bang on the registers via PAC and manage concurrency yourself, I think it's quite usable, but the learning curve is quite steep.