Hacker News Reader

Comment by j-james | Hacker News Reader

A possible alternative to MicroPython is Nim - it's a strongly typed language with Python-like syntax that compiles down to C. Since it compiles to C, it can use existing C libraries without much fuss (just wrap signatures as needed), plus there's no need for a "micro" version of the language.

Several members of the community have been working on improving the embedded ecosystem: although I haven't played around with either yet, the nesper library (for the ESP32) and ratel (generic framework: tested for the Arduino/AVR) have been recommended.

https://nim-lang.org/

https://github.com/elcritch/nesper/

https://github.com/PMunch/ratel

View on HN

I've been using Nim and Nesper for the firmware of a device I'm making, it's been mostly great. Nim's C interop is painless, anything Nesper hasn't already wrapped can generally be pulled in from the official C libraries in one shell command. My only headache with Nim on the ESP32 is that the official framework doesn't provide a full POSIX implementation so some stdlib functions don't work.

https://github.com/khogeland/pxed/

Hey awesome to hear others are using my Nesper! Nice to read through your repo and see what style of Nim coding you used (low level C-like constructs vs higher level Pythonic ones). Feel free to post PR's, I try to merge them once a month.

Nim, Zig, Julia, Rust, so many languages lately ... anyone else with language-choice anxiety?

Not really. Probably only a single-digit percentage of software developers will ever get to use any of these professionally. Howl in protest if you will, but the truth is that all of these (and more) are mostly the domain of students and hobbyists.

If you are already in the industry, and part of the 90+% unwashed masses, then you already know this. If you are a student or hobbyist who hasn't clued into this reality yet, then there's no need for "language-choice anxiety". Play with whatever you want to play with, and once you graduate you should have no problem transferring that knowledge to whatever language your first real job actually pays you for (e.g. Java, Python, C#, etc).

This is mostly true, but (I cannot believe I am going to do this), Rust is in a different tier compared to the other languages in the list.

From the last who is hiring thread:

Zig =0 mentions

Nim = 0 mentions

Julia = 2 mentions

C# = 4 mentions

C++ = 12 mentions

Rust = 13 mentions

Java = 18 mentions

JavaScript = 30 mentions

Python = 50 mentions

The threads here are not indicative of the overall market and 1 mention != 1 job, but the numbers above are pretty much in line with the proportion of offers I am seeing elsewhere.

I should not have chosen Pascal as my primary programming language.

It is not even mentioned when looking for uncommon language mentions

While at it dont forget TinyGo. Im a hobbyist occasionally working on potentially commercial ideas. ARduino is great to start learning. PlatformIO i found very supportive with tools for everything I needed and wide board support. Used to code a lot in Python. My next project i will use TinyGo to see the degree of correspondence with full desktop Go and beyond that im inclined to try Ada next as for bare metal code the idea of using Ada just seems to make a whole lot of sense given its application to control systems over the decades.

My 2c

For micro-controllers having a choice in language is very new and there is still very few languages to pick from. Chip vendors only support C/C++, sometimes only barely.

Many languages (if it is AOT compiled and uses LVVM you can probably get it running on a uC) have POCs for running on an a uC, but often lack the HAL (libraries to use all the peripherals).

Nim is a very good choice because it generates tiny binaries while having a very expressive syntax.

It's the closest language to a static typed Python.

Also it uses GCC, which supports most microcontrollers.

If you work with the developers of those projects let them know that many details of an embedded CPU are generated by code. It's an important step to break the cycle of re-encoding information produced by machine in microcontroller standard libs.

I think with current parts the only way would be to focus on RISC-V, but who knows. They might have better luck talking to vendors.

Reply on news.ycombinator.com