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

spent most of my career either in kernel land where you account for every byte yourself, or in nodejs/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. 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, were 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 its an embedded target again, because it is one. other thing nobody warns you about is theres almost no ecosystem outside garmins own forums. stack overflow is basically empty so you end up digging through old firmware bug threads to figure out why something behaves diferently on device vs sim. 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 its a nice reset. submitted by /u/Robservant [link] [留言]