Azure Sphere OS was designed to fit in a 4MB of SRAM envelope... while actually using a Linux kernel.

If I remember well, only 512KB is actually usable by OEM applications on that platform.

And?

I was using C++ on MS-DOS.

Not even C++ is supported on the Azure Sphere OS SDK.

Ironically they usally tend to evade the question when asked about it, to the point they ended up writing a very long blog post trying to justify C, and it had nothing to do with space requirements.

Rather industry expectations and other marketing speak.

The libc and libraries that they already add to apps don't leave enough space for an off-the-shelf C++ runtime to be included.

So instead of including a custom runtime they just bailed out...

And? Turbo and Borland C++ also had their off-the-shelf C++ runtime to fit into either 64 KB COM files or up to 512 KB memory space with EXE.

In fairness, back then C++ was a much smaller superset of C than it is now.

Same applies to C.

Anyway just search for Jason Turner's talks on targeting Commodore 64 with C++.

Not really. That is, C's libraries grew less than C++'s libraries, over the past 25 years or so.

Do you use everything on the standard library? Uau.

Also people are using glibc++ on avr micro controllers.

So they are not using RUST because it is bloated but for other will be ok to use it. Linux kernel is already quiet bloated so i don't see what rust can bring. BSDs start looking more and more interesting.

> So they are not using RUST because it is bloated but for other will be ok to use it.

No. They are only using C. They are not using anything else for "unknown" reasons.

You can write bloated Rust applications in pretty much the exact same ways you can write bloated C applications (generics, runtimes, macros, ...).

And you can write thin Rust applications in pretty much the same ways you can do so in any other language, including C.

Tangentially, on what parameters is the linux kernel bloated?

I presume it's mostly that the kernel ships so many drivers.

A huge number of them is in the form of downloadable modules, that is, if you don't connect the hardware, the relevant module isn't loaded.

It is better when others have skin in the game and you are protected from risks. The fool doesn't learn from his own mistakes, the smart one learns from his own mistakes, the wise learns from the mistakes made by others. Very wise Azure people are. :)

Obligatory "The S in IoT stands for Security"