5 ms·

nimbme – Nim bare-metal environment

ronsor 1y ago
Since Nim compiles to C, porting it to new platforms is surprisingly easy. I did it a few years ago for 16-bit DOS (OpenWatcom): https://github.com/Ronsor/Nim/tree/i086-and-watcom https://github.com/Ronsor/Nim/tree/i086-and-watcom.
- cb321 1y ago
  While there are several "OS in Nim" projects (https://github.com/khaledh/fusion https://github.com/khaledh/fusion is probably the most interesting), this same ability to run bare-metal and generate to C should, in theory, make it possible to write kernel modules in Nim for Linux/SomeBSD without any special permission slip / drama over integration (the way Rust suffers, for example). I haven't heard of anyone doing such modules, but it might be a fun project for someone to try.
  - PMunch 1y ago
    Well, the C that Nim outputs isn't exactly human readable. Sure if you know what you're doing you might be able to follow along, but no sane maintainer would admit it into a C project. It could help the build process a you can pre-compile to C and only use the C build system. And it allows you to run anywhere C can run (we use it for everything from servers to microcontrollers). But apart from that it's mostly an implementation detail.
    - cb321 1y ago
      My idea is not to submit the generated C any more than you submit C-compiler generated assembly, but to write directly in Nim. The niceness would mostly just be if you wanted to write some complex thing like a filesystem or driver in Nim with its templates & macros & user-defined operators and DSL building and all that goodness. Being a module means it can be separately distributed - kernel maintainers don't need to admit them or even be aware of them. ZFS is not distributed in mainline Linux out of Oracle fears (though that module is popular enough some distros help out). This is more or less the key to any extensible system. The C backend is helpful here in that internal kernel APIs can rely heavily on things like the C preprocessor, not just object file outputs. I think the main challenges would be "bindings for all the internal kernel APIs" and the ultimately limited ability &| extra work to make them Nimonic and adapting the "all set up for your C module" build process to ease a Nim build (as well as the generic in-kernel no-stdlib hassles). So, I imagine a 2- or 3-level/stage approach would be best - the background to make the Nim modules easy and then actual modules. { Linux itself, while the most popular free Unix, is also kind of a faster moving target. So, it would probably present an additional challenge of "tracking big shifts in internal APIs". }
- snac 1y ago
  Pleasantly surprised about the ease of porting to new platforms. Being able to inline assembly, nevermind call regular C functions (eg from an OEM SDK) is incredibly handy. I recently wrote a pure Nim implementation for the CH32V003 microcontroller https://github.com/snacsnoc/nim-on-ch32v003 https://github.com/snacsnoc/nim-on-ch32v003
yapyap 1y ago
oh nim nim nim nim nim, fucking nim shoutout if you got that [reference](https://youtube.com/watch?v=Z7PH36ZAao4 https://youtube.com/watch?v=Z7PH36ZAao4)
hugs 1y ago
Happy to see more Nim projects on HN! I don't know if AI code gen helped with this particular project, so please forgive my small tangent; Claude Code is surprisingly good at writing Nim. I just created a QuickJS + MicroPython wrapper in Nim with it last week, and it worked great! Don't let "but the Rust/Go/Python/JavaScript/TypeScript community is bigger!" be the default argument. I see the same logic applied to LLM training data: more code means more training data, so you should only use popular languages. That reasoning suggests less mainstream languages are doomed in the AI era. But the reality is, if a non-mainstream language is well-documented and mature (Nim's been around for nearly 20 years!), go for it. Modern AI code gen can help fill in the gaps. tl;dr: If you want to use Nim, use Nim! It's fun, and now with AI, easier than before.
- ternaryoperator 1y ago
  Is there a reasonably good IDE for Nim that provides debugging, specifically the full debugging experience (Nim code rather than C, breakpoints, inspect/modify values, etc.)? That's been the gating factor for me trying it. What's the present situation?
  - hugs 1y ago
    I'm using Claude Code... And then for manual review and editing, using Zed with Nim extensions: https://zed.dev/docs/languages/nim https://zed.dev/docs/languages/nim Sorry, I don't really do debuggers... I mostly step through code interactively using a REPL (INim).
    - aryonoco 1y ago
      I ran into some problems with Zed and Nim which I eventually solved by enhancing the LSP’s settings. This might be useful for anyone interested https://blog.ameri.coffee/using-zed-for-nim-development https://blog.ameri.coffee/using-zed-for-nim-development
  - HexDecOctBin 1y ago
    Does Nim not output the #line directives when compiling to C? That alone should help with the debugging experience.
the__alchemist 1y ago
Nice to see more embedded language options!
pmarreck 1y ago
Nim seems underrated. A nice balance of utility, longevity, speed, and coding niceness.
- corv 1y ago
  Happy to see it get more attention here - it really is versatile
- ryukoposting 1y ago
  I was active in the community for several years before getting too busy with other things. Good folks.

Since Nim compiles to C, porting it to new platforms is surprisingly easy. I did it a few years ago for 16-bit DOS (OpenWatcom): https://github.com/Ronsor/Nim/tree/i086-and-watcom https://github.com/Ronsor/Nim/tree/i086-and-watcom.

cb321 1y ago
While there are several "OS in Nim" projects (https://github.com/khaledh/fusion https://github.com/khaledh/fusion is probably the most interesting), this same ability to run bare-metal and generate to C should, in theory, make it possible to write kernel modules in Nim for Linux/SomeBSD without any special permission slip / drama over integration (the way Rust suffers, for example). I haven't heard of anyone doing such modules, but it might be a fun project for someone to try.
- PMunch 1y ago
  Well, the C that Nim outputs isn't exactly human readable. Sure if you know what you're doing you might be able to follow along, but no sane maintainer would admit it into a C project. It could help the build process a you can pre-compile to C and only use the C build system. And it allows you to run anywhere C can run (we use it for everything from servers to microcontrollers). But apart from that it's mostly an implementation detail.
  - cb321 1y ago
    My idea is not to submit the generated C any more than you submit C-compiler generated assembly, but to write directly in Nim. The niceness would mostly just be if you wanted to write some complex thing like a filesystem or driver in Nim with its templates & macros & user-defined operators and DSL building and all that goodness. Being a module means it can be separately distributed - kernel maintainers don't need to admit them or even be aware of them. ZFS is not distributed in mainline Linux out of Oracle fears (though that module is popular enough some distros help out). This is more or less the key to any extensible system. The C backend is helpful here in that internal kernel APIs can rely heavily on things like the C preprocessor, not just object file outputs. I think the main challenges would be "bindings for all the internal kernel APIs" and the ultimately limited ability &| extra work to make them Nimonic and adapting the "all set up for your C module" build process to ease a Nim build (as well as the generic in-kernel no-stdlib hassles). So, I imagine a 2- or 3-level/stage approach would be best - the background to make the Nim modules easy and then actual modules. { Linux itself, while the most popular free Unix, is also kind of a faster moving target. So, it would probably present an additional challenge of "tracking big shifts in internal APIs". }
snac 1y ago
Pleasantly surprised about the ease of porting to new platforms. Being able to inline assembly, nevermind call regular C functions (eg from an OEM SDK) is incredibly handy. I recently wrote a pure Nim implementation for the CH32V003 microcontroller https://github.com/snacsnoc/nim-on-ch32v003 https://github.com/snacsnoc/nim-on-ch32v003

yapyap 1y ago

oh nim nim nim nim nim, fucking nim shoutout if you got that [reference](https://youtube.com/watch?v=Z7PH36ZAao4 https://youtube.com/watch?v=Z7PH36ZAao4)

hugs 1y ago

Happy to see more Nim projects on HN! I don't know if AI code gen helped with this particular project, so please forgive my small tangent; Claude Code is surprisingly good at writing Nim. I just created a QuickJS + MicroPython wrapper in Nim with it last week, and it worked great! Don't let "but the Rust/Go/Python/JavaScript/TypeScript community is bigger!" be the default argument. I see the same logic applied to LLM training data: more code means more training data, so you should only use popular languages. That reasoning suggests less mainstream languages are doomed in the AI era. But the reality is, if a non-mainstream language is well-documented and mature (Nim's been around for nearly 20 years!), go for it. Modern AI code gen can help fill in the gaps. tl;dr: If you want to use Nim, use Nim! It's fun, and now with AI, easier than before.

ternaryoperator 1y ago
Is there a reasonably good IDE for Nim that provides debugging, specifically the full debugging experience (Nim code rather than C, breakpoints, inspect/modify values, etc.)? That's been the gating factor for me trying it. What's the present situation?
- hugs 1y ago
  I'm using Claude Code... And then for manual review and editing, using Zed with Nim extensions: https://zed.dev/docs/languages/nim https://zed.dev/docs/languages/nim Sorry, I don't really do debuggers... I mostly step through code interactively using a REPL (INim).
  - aryonoco 1y ago
    I ran into some problems with Zed and Nim which I eventually solved by enhancing the LSP’s settings. This might be useful for anyone interested https://blog.ameri.coffee/using-zed-for-nim-development https://blog.ameri.coffee/using-zed-for-nim-development
- HexDecOctBin 1y ago
  Does Nim not output the #line directives when compiling to C? That alone should help with the debugging experience.

the__alchemist 1y ago

Nice to see more embedded language options!

pmarreck 1y ago

Nim seems underrated. A nice balance of utility, longevity, speed, and coding niceness.

corv 1y ago
Happy to see it get more attention here - it really is versatile
ryukoposting 1y ago
I was active in the community for several years before getting too busy with other things. Good folks.