On embedded systems, it is quite common to have cut down libraries that only support a subset of types. e.g. floating point formatting is quite regularly left out.

Not really.

It seems the problem for the author is that either they get string based output with a big printf, or no printf at all, and replacing printf is hard. In c replacing printf with a tiny limited implementation is easy and common.

Printf is basically a runtime interpreter, which has better code size, and worse performance, than the typed template magic that Rust uses. As other comments point out, though, printf in C can be a performance problem in embedded for this reason. Pick your poison…

Yes, in the sense that calling it anywhere will pull in a lot of stdlib stuff by default. But no, in that it's trivial in C to write your own minimal printf replacement. Because of the nature of linking in C, it will override all uses of it.

In practice no, for several reasons:

Embedded compilers quite often will include two implementations of printf/sprintf - 'minimal' and 'full' (like solution 2 in the post). Usually the 'minimal' implementation doesn't have floating point support and suchlike so is sufficient for normal debugging output.

The sort of libraries that you depend on in embedded development don't implicitly print. There's none of the 'implicit panics will cause an extra 15k of space'.

It's a normal symbol fed to the linker rather anything special and compiler managed so it can be overriden if necessary.

C doesn’t have ubiquitous calls to panic, so even if it did you generally don’t get it unless you do something which more obviously interacts with the formatting parts of the standard library.

When using FreeRTOS tasks, any use of printf() requires a substantially larger stack allocation per task. But I don't recall now any massive blow-out in binary size.

Yeah canned printf is really stack heavy if I remember. A solution is to have one thread that handles printf. Biggest issue I've run into with printf at least in C is calling it tends to be expensive.