>First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.
You still have to give the literal value of the field instead of using the auto-incrementing enum but that's how I do it in C as well, I find it too error-prone otherwise. And how do you deal with fields that take up multiple bits anyway?
>Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
I agree 100%. I can understand them prioritizing higher level system programing and taking the time to do asm right, but it does make it a bit of a pain to do bare metal Rust at the moment.
>Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
What do you have in mind here? format! is strongly typed and a lot more flexible than printf. You can't even print custom structs with printf... Actually even printing standard types like uint32_t and friends require macro soup to work portably.
Variadic arguments are pretty much a no-go for a strongly typed, static language since you would need a lot of trickery to get it to work safely under the hood (hence format! being a macro).
But what use case do you have for printf that can't be implemented with println!/format! and friends?
> But what use case do you have for printf that can't be implemented with println!/format! and friends?
I'm guessing they mean that the format! machinery is rather complex and brings in a lot of code. That it's also somewhat slow is a recurring concern .
Have none of the embedded folks created a specialised version of format! which is not generic, and basically only supports the types and styles which c's printf supports?
There's defmt which I think i think is even better (it implements basically the same thing as I have used in a commercial C++ embedded project for a few years, and was sorely missing any open source equivilent when I was first trying to implement it). formatting strings on an embedded device is pointless and wasteful. Heck, formatting log lines before they are displayed to the user is actively harmful to interpreting them! Defmt basically gives embedded projects structured logging and a substantial bandwidth, cpu, and space overhead gain.
defmt looks cool for logging but I'd think there are cases where you want to format strings somehow in order to present them to the user e.g. audio track information or whatnot.
Have a look at the bitlags crate, I use it a lot for this purpose: https://docs.rs/bitflags/1.2.1/bitflags/
You still have to give the literal value of the field instead of using the auto-incrementing enum but that's how I do it in C as well, I find it too error-prone otherwise. And how do you deal with fields that take up multiple bits anyway?
>Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
I agree 100%. I can understand them prioritizing higher level system programing and taking the time to do asm right, but it does make it a bit of a pain to do bare metal Rust at the moment.
>Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
What do you have in mind here? format! is strongly typed and a lot more flexible than printf. You can't even print custom structs with printf... Actually even printing standard types like uint32_t and friends require macro soup to work portably.
Variadic arguments are pretty much a no-go for a strongly typed, static language since you would need a lot of trickery to get it to work safely under the hood (hence format! being a macro).
But what use case do you have for printf that can't be implemented with println!/format! and friends?