shoutout if you got that [reference](https://youtube.com/watch?v=Z7PH36ZAao4)
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.
Sorry, I don't really do debuggers... I mostly step through code interactively using a REPL (INim).
OK, THIS is interesting!
mostly at the level of Nim source, although various things are likely to "leak through" like mangled names (though in fairness, lower-level assembly notions leak through in "C source level" debugging...).
Beware, though, that since around Spring 2024 this can make the tinycc/tcc backend infinite loop (but otherwise tcc can be a nice way to get fast development iteration).
Meaning you get pretty function names with generic types and all included with debuggers that support it. Works better with ldb as gdb seems to refuse to recognize it.
Both Nim and F# have strong types and strict compilers (arguably more strict in case of F#). These factors matter a lot more than how much code there is for the LLM to train on. And there probably is less ostensibly bad Nim and F# code out there than old Python code written by people who were not really developers, so the training data set is higher quality.
I used Claude 4 to generate SIMD versions of signed distance functions for both NEON and SSE2 and it all worked and compiled fine the first time aside from some minor import changes [1]. Gave me an almost 4x increase for many SDFs.
I also use Atlas, an alternative package manager for Nim [2], to clone deps into a local folder which lets Cursor grep and search the dependencies to add it to the context as needed.
1: https://github.com/elcritch/sdfy 2: https://github.com/nim-lang/atlas
ronsor•7mo ago
cb321•7mo ago
PMunch•7mo ago
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•7mo ago
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•7mo ago