nesper

Looks fun! I recently updated my Nim wrapper for esp32 for esp-idf 5.5 [1]. I've been wanting to play with a graphics device, maybe via Tactility.. Also the integrated usb-phy on newer esp32s is pretty handy. I setup a driver to do PPP (!) connection over a USB-CDC serial port with a second serial port for logging [2]. All in 200 lines of Nim and a few Codex/GPT5 prompts. I got a multithreaded MsgPack RPC server over the PPP connection using IPv6. Unfortunately you can't use CDC mode and USB JTAG, so I have a little rpc based binary uploader. 1: https://github.com/elcritch/nesper 2: https://github.com/elcritch/nesper/blob/devel/src/nesper/net...

My favorite serde format is Msgpack since it can be dropped in for an almost one-to-one replacement of JSON. There's also CBOR which is based on MsgPack but has diverged a bit and added and a data definition language too (CDDL). Take JSON-RPC and replace JSON with MsgPack for better handling of integer and float types. MsgPack/CBOR are easy to parse in place directly into stack objects too. It's super fast even on embedded. I've been shipping it for years in embedded projects using a Nim implementation for ESP32s (1) and later made a non-allocating version (2). It's also generally easy to convert MsgPack/CBOR to JSON for debugging, etc. There's also an IoT focused RPC based on CBOR that's an IETF standard and a time series format (3). The RPC is used a fair bit in some projects. 1: https://github.com/elcritch/nesper/blob/devel/src/nesper/

I use Nim on embedded precisely for that reason: https://github.com/elcritch/nesper I wtapped much of zephyr as well but that ones less used: https://github.com/embeddednim/nephyr

Nim supports both since it compiles with pretty much any C89 C compiler. Also https://github.com/elcritch/nesper :)

Checkout Nim! I've used it to great effect for embedded programming. It has memory management system based on non-atomic reference counting (arc) so its fast and deterministic. It has optional cycle collection too (orc). Its easy to mixin manual memory as well. I used F# a bit and learned a lot from it, and the same with Elixir and Nerves. Nim is procedural but it has an "enlightened procedural" take that feels like functional programming in some ways. Partly thats due to the very powerful type system - for example Nim lets you define custom distinct (not aliased) number types just like F#. Nim also inherits a fair bit from Pascal and so shares points with Ada like ints with custom ranges. Theres some rough points, but largely its made me enjoy programming again. The esp32 is a good intro route since they're easy to setup. I wrote a wrapp

You should checkout Nim! I use it extensively on embedded. Nim is fantastic to program in if you're an experienced C/C++ developer. Its safer and smarter but not not pedantic about it. Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity). Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces

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

Nim also has some pretty good ESP32 bindings: https://github.com/elcritch/nesper

I would really like to see more work on improving the use of Nim for programming microcontrollers. I stumbled on to https://github.com/elcritch/nesper recently and it looks neat, but I had issues getting my code to compile. Improved support for other MCUs like the esp8266 and atmega32u4 would be really cool and useful. It would be nice to have Nim as a higher level alternative to micropython or lua in the embedded world (your only other real alternatives being C/C++ or Rust). I also found this https://disconnected.systems/blog/nim-on-adruino

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For something Flask-like: https://github.com/dom96/jester or something with more defaults https://github.com/planety/prologue * Scientific computing: the wonderful SciNim https://github.com/SciNim * Blockchain: Status has some of the biggest Nim codebases currently in production https://github.com/status-im?q=&type=&language=nim&sort= * Gamedev: Also used in production: https://github.com/pragmagic/godot-nim and due to easy C

Oh yes, Nim definitely feels like an alternate reality where Python 2 became static and dumped some poor design choices. Well I believe there's room between Rust and Python where Nim can grow. It made the TIOBE top 50 lately even. Likely it can eat enough market share from the edges of both Rust & Python to become more well known (more libs, tools, etc). Rust is fantastic but tedious to program (to me at least) and it's community focuses on more formal type traits, etc making "scripting" trickier. Python is great for a mix of quick scripts, web dev, and data science but it's slow enough (and getting complex enough!) for many to want something faster and more stable yet still easy to write. Nim lives in between them and is more enjoyable to write than either for many. Also, Nim _could_ add Rust as a backend target and be relevant even if R

Not quite sure if I follow what you're saying. As in Tasmota/Berry do or do not do more than provide I2C/SPI? > If one wants to do serious stuff they would use an appropriate RTOS and program it in C. It's unfortunate, but still largely appears to be the case. I find C very time consuming to program, so I ported Nim to FreeRTOS [1]. It's _very_ nice being able to go from writing highly optimized ISR functions to high level JSON parsing in one language. Add in defaulting to memory safety but with no pause-the-world GC. I tried Rust but it seems more difficult to integrate into existing world RTOS'es, flashers, Swagger debuggers, etc. Though, I've been curious what running a WASM VM would be like? One could integrate any language: C++, C, Nim, Rust, etc. Would be interesting. > MongooseOS does more than this if we're talking ESP32, also oth

Note I’m using Nim with the new GC (both ARC & ORC) on dual core esp32’s. Locks do work with ARC, though some care needs to be taken. Both the Nim and free-rtos multi-threaded queues work well with the correct move/sink annotations. The design of ARC allows you to move entire memory graphs between separate heaps. It works fine, but what’s not working is the compile time verification that a given memory graph is only owned/aliased by the top pointer. So there’s a lot of work to do in making it “safer and easy” to use. Here’s an example: https://github.com/elcritch/nesper/blob/f54fff8b240e94684ae8...