[PMunch]

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]

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". }