embedpythony

It already does! (As long as the target supports LLVM)

https://rust-embedded.github.io/book/

To be fair, there are BSPs for cheap chips like Espressif microcontrollers and a myriad of minimal development boards. You don't need to buy a pyboard, and part of the reason those are so expensive is because they help fund the project's continued development.

But it definitely does have issues with memory usage. Personally, I hope that it will become more viable as its development continues and RAM densities increase. I love the syntax and ease-of-use, but I don't love needing a $10 chip for a $1 task. Hopefully it'll be usable for non-trivial tasks on a $1 Cortex-M23 chip in a few years.

It also really shines in educational environments. I see a lot of promise in the progression from MakeCode (primary school) to MicroPython (middle/high school) to programming "real computers" (high school/college). It's a natural progression, and understanding simple microcontrollers takes a lot of the scary "magic" out of learning about complex application processors. See, for example, the BBC micro:bit (which also has a MicroPython BSP).

There are a few reasons. Number one, stability issues from heap fragmentation.

http://docs.micropython.org/en/latest/reference/constrained....

Even if you are careful about manual allocation, Python is not a compiled language, and the interpreter will frequently request heap allocations on its own. So if you expect a program to run for a long time without crashing, you'll probably need to use much less memory than the system has available.

It's also quite slow. That's not a huge issue since modern microcontrollers are fast and you can write your own .mpy modules in C, but it does affect power consumption.

It's also pretty high on the "drama" scale as far as OSS projects go. Last I checked, there was a brewing split between the original maintainer and one of the largest contributors, and Adafruit have already gotten frustrated enough to make a hard fork called CircuitPython.

Personally, I would use it a lot more if I could trust it to run stably. For reference, I've used it in a Cortex-M0 clock which can run more or less indefinitely, but needs 16-32KB of RAM just to read an I2C clock and set some 7-segments. And when I tried to set up a simple wireless MQTT sensor with a supported Cortex-M4 board, I couldn't get it to run longer than a few days before the application crashed from memory fragmentation.

So from my perspective, it is only usable for trivial tasks, and even if it were more stable, I'm not sure which fork would be the right choice for long-term development.

Still, it's an excellent educational tool and I always like to see more of those.