wrote my first Garmin app in Monkey C and its the strangest middle ground ive coded in years

First Impressions of Monkey C

Spent most of my career either in kernel land where you account for every byte yourself, or in Node.js/NestJS world where you just throw objects around and let the runtime sort it out. Monkey C is neither, and it kept messing with my instincts.

The lead dev once described the goal as wanting something that looked like JavaScript but with no features that waste memory - basically "syntactic Splenda" instead of sugar. So you get this language that reads like JS, but the second you write JS-brained code, it punishes you.

Memory Constraints

The part that actually got me was memory. Everything ran perfect in the simulator and then crashed on the actual watch with out of memory. Turns out watch faces get a tiny slice of RAM compared to full apps, and the older devices are brutal about it - we're talking double-digit KB for the whole thing.

Coming from a runtime where I never think about allocation, it was kind of humbling to go back to counting objects like it's an embedded target again - because it is one.

Ecosystem Challenges

Other thing nobody warns you about: there's almost no ecosystem outside Garmin's own forums. Stack Overflow is basically empty, so you end up digging through old firmware bug threads to figure out why something behaves differently on device vs. sim.

Final Thoughts

Weirdly, I enjoyed it more than I expected. It scratched the same itch as kernel work - real constraints and no abstraction to hide behind. Would not want it as a day job, but as a side thing, it's a nice reset.