nephyr VS RFCs

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

It's funny how something like Zig's comptime of C++'s constexpr get 90% of the way to solving most compile time issues, but can't knock out that last 10%. Compile time database types sound like one of those cases. F# had a feature for compile time types via "type providers". It seemed _really_ cool at first, but in practice is was a bit fragile.

Though on the other hand I'm using compile Nim code to parse CMake files and provide static types for configuration values. It's super easy in Nim between macros and const's. Here's a ~170 lines of code where I'm compile time checking that my Nim code can compile time check against the current build configuration of Zephyr RTOS https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...

Nesper author here, unfortunately I haven’t had time to fix the compile issues on all the esp-idf branches. Please feel free to file an issue as I don’t use es-idf/Nesper often now but I’ll respond to issues. The main branch should be more stable too.

I’ve been moving development to Zephyr RTOS since it supports many more boards and is more stable. I’d recommend trying it out but note it’s a WIP. I haven’t figured out templated examples yet. I’ve covered lots of api areas but not all. My goal is to make it into a broad MCU platform for Nim — Nephyr: https://github.com/EmbeddedNim/nephyr

But yah Nim can run on most anywhere you can compile C to. Some people just got Nim CMSIS working. I’m hoping to get more people involved at github.com/EmbeddedNim project to support more mcu’s. Testers are welcome!

compiler support for object construction shorthand

Well, maybe not writing. Occasionally low-level C libraries - especially those that deal with keyboard input - decide to provide identifiers differing only in case... There's a WIP RFC for providing a way to deal with identifiers that need to be verbatium by surrounding them with backticks, though.

https://github.com/nim-lang/RFCs/issues/477

Following The Roadmap 2023 for community building , you could join us in the matrix space where we discuss how to build a community. We appreciate doable suggestions and helps, such as improving the workflow, implementing the roadmap, suggesting doable tasks, reviewing code from contributors. United we stand. We shall work together to make the community thrive.

First of all, the Nim development follows The Roadmap 2023, which specifies what features might be implemented or removed in 2023. As we can see, completing incremental compilation and recursive module dependencies might be the most important tasks to be done in 2023. You might subscribe to the roadmap and write down your expectations of Nim in 2023 there.