C# is the language with the best degree of control over allocation among all GC-based languages. You can write code that is completely allocation-free including abstractions. Most "data processing" APIs in the standard library do not allocate at all or allocate once for initializing e.g. lookup tables.
The actual issue is existing selection of runtimes for embedded platforms is limited: https://nanoframework.net/ and https://www.wildernesslabs.co/device (to be fair, a friend of mine uses the second one for automating his lab for his microfluidics devices research project, so it is useful).
You can :) It just requires going out of your way a bit. It effectively works as C with better type system and generics (C++ lite if you will), that can be either JIT or AOT compiled (statically linked too). For example https://github.com/bflattened/bflat has a target flavour that does not support GC at all.
I'm not saying it's an optimal choice for embedded, only pointing out that you can write allocation-free code with confidence. Patterns that allocate are known - predominantly boxing and closures. You can easily avoid both, you can also declare your structs as 'ref struct' which completely prohibits placing them on the heap, either as a box or as a part of heap-allocated memory inside some other object/struct.
Is it really true though? I don't have much knowledge about embedded development, but as far as I know, Java has been used in many embedded systems, and was running on phones' SIM-cards. Please correct me if I am wrong.
I think that most modern embedded systems are nowadays more powerful than my first desktop computer — is it really still worth for the majority of embedded projects to count every byte at the expense of developers' productivity (and overall project success, as a result)?
SIM cards are a weird exception because they have a hardware computer designed to run a subset of Java. Normally Java compiles to a bytecode which is run by the Java VM - in SIM cards the VM is a hardware implementation of the Java VM. That's super uncommon - most processors in the world have a different instruction set, like ARM or RISC or x86. Java can't compile to instructions in those languages. Rust can.
Yes, you can run a VM on one of those processors in which you run a language like C# or Java. Look at MicroPython as a successful example. But the code which runs that VM has to be written in something. Typically that has been C and C++ - but Rust can also do it.
You're right though - a lot of what we call "embedded computing" could be done using a modern VM interpreted language. There are some languages out there - MicroPython and Squirrel come to mind - which can run on the memory and storage constrained environment of a microcontroller. The mainstream implementations of Java and C# use way to much memory - they've been optimised for desktop environments. Microcontrollers often have 64 - 1024 kB of RAM.
You could ship products with application processors like the Raspberry Pi, running an OS, and write your application in whatever language you like. But that costs 1-2 orders of magnitude more money. A cheap microcontroller is $1. By the time you've added the RAM, flash and supporting power rails, a cheap application processor is $10+. Then you have to maintain an OS - that's a lot of engineering time. Sometimes it's worth it, sometimes it's not - the tradeoff depends on the product.
Not sure how well it fits reality, but it’s also to a large extend how dramatic can be the result of a fault of your system.
If it’s embedded in a coffee machine, maybe all cost-effective taken into account it’s ok to have an over-bloated software stack maintained by the cheapest folk the manager could found.
Now if you are working on embedded software for some vehicle like a critical part of a car, a train or a spaceship, considerations of safety for both ethic and legal reasons might lead to different tradeoffs and conclusions.
I would argue that using JSON in embedded, especially on ESP32, is another no-go. I'd wage that using a binary format and later on, after you're out of ESP32, convert it to JSON would be a bigger performance gain than the evangelic tone of this article vis-a-vis of Rust.
C# is garbage collected. This is a no-go in many/most embedded software applications.
C# also grants you poor explicit control over heap/stack allocation: this is essential for embedded development.