[jeroenhd]

I don't think the requirements for your specific programming niche should influence the language like that. Your requirements are valid, but they should be served by a bottom of the barrel microcontroller compiler rather than the language spec.

[MobiusHorizons]

It’s relevant because the author mentions microcontrollers as the reason for focusing on binary size.

[Karliss]

There are many orders of magnitude difference between smallest and higher end microcontrollers. You can have an 8bit micro with <1k of ram and <8k of flash memory, and you can have something with >8MB of flash memory or more running a RTOS possibly even capable of running Linux with moderate effort. In the later case 14k of formatting library is probably fine.

[jeroenhd]

All of the optimisation work in this article is done for Linux aarch64 ELF binaries.

Besides that, microcontrollers have megabytes of storage these days. To be restricted by a dozen or two kilobytes of code storage, you need to be _very_ storage restricted.

I have run into code size issues myself when trying to run Rust on an ESP32 with 2MiB of storage (thought I bought 16MB, but MB stood for megabits, oops). Through tweaking the default Rust options, I managed to save half a megabyte or more to make the code work again. The article also links to a project where the fmt library is still much bigger (over 300KiB rather than the current 57KiB).

There are microcontrollers where you need to watch out for your dependencies and compiler options, and then there are _tiny_ microcontrollers where every bit matters. For those specific constraints, it doesn't make a lot of sense to assume you can touch every language feature and load every standard library to just work. Much older language features (such as template classes) will also add hundreds of kilobytes of code to your program already, you have to work around that stuff if you're in an extremely constrained environment.

The important thing with language features that includes targets like these is that you can disable the entire feature and enable your own. Sharing design goals between x64 supercomputers and RISC-V chips with literal dozens of bytes of RAM makes for an unreasonably restricted language for anything but the minimal spec. Floats are just expensive on minimum cost chips.

[MobiusHorizons]

Pretty much anything in the Arm M0+ will be in the 4kb / 8kb / 16kb flash range and anything in the M3 class will typically be in the 64kb / 128kb flash range. These are small microcontrollers, yes, but they the typical microcontroller I would reach for when doing something that is not algorithmically intensive. Microcontrollers such as this are more than capable of responding to user input, running an LCD screen, or interfacing with peripherals. With 128kb maybe I could burn 14kb (~11%) on a string formatting library, but that seems pretty excessive to me.