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.

Adafruit's fork was for business reasons as they wanted control over implementation for the hardware they sell, and to focus development efforts on making it more accessible to newcomers. While I'm not thrilled with the fork since it dilutes the original project imo, they do still contribute back to the micropython project. But I don't think there's any lost love there, they just had different goals with a financial stake (unlike the uasyncio split which was ego driven)

I have an ESP8266 running MQTT to make an alert on a speaker (I2C) on demand. I just looked at the counter I periodically send to MQTT. It has been up for over 200 days. It does not leak.

When you have a product that is running out of flash and you want to deploy an update for your customers, you need that granular control.

I just can’t fathom deploying a full product where I don’t have this sort of control?

From a performance/space standpoint there is decades of compiler optimization experience with IAR/GCC, I’m not sure micropython can achieve that.

I don't think it's inconceivable that there would be a product where you'd have ample storage and CPU power for your application and would want to optimize for speed of development instead. I've built things on MicroPython that would be just fine to ship as they were, for example, if I were to commercialize them.

When engineers start cutting corners and start to design not for performance but “speed of development” — it becomes a slippery slope.

I guess I’m speaking from the standpoint of a firmware engineer, I honestly don’t think going with micro-python for our next product will buy us anything.

However, as I said; if you’re not into firmware and/or just getting started, this makes a great prototyping language.

If you're a firmware engineer and already familiar with the ins and outs of C, I don't think it buys you anything, agreed. I also don't think there's something fundamentally wrong with it that would force a hobbyist to rewrite everything in C if they wanted to commercialize their prototype.

I can agree with this. If you find a language that is more approachable and gets stuff done, you should go for it.

(And hopefully get sucked into firmware(I wish we had more firmware-engineers ;-) ))

For me, some of the hardware supported by MicroPython is more powerful that what I had on a desk during my MS-DOS days, so I can easily see using it for certain kinds of applications.

If it was good enough to run Turbo Basic, Quick Basic, Turbo Pascal, Turbo C++, Clipper, it can easily take MicroPython.

you're being a little hyperbolic. haven't you ever heard of premature optimization?