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.
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?
I see comments like this fairly often and in my entire career (I'm 53) I've never had to use a debugger. For inspection of values, I write small functions and unit tests or just output to stderr in debug modes set with env vars. I've always thought that the need to use a debugger was a code smell- too much cyclomatic complexity of single functions.
My experience has been the same. I have found it much easier to write good Nim and F# code with Claide Code, than say modern Python with type hints everywhere.
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.
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.
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.
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?
I'm using Claude Code... And then for manual review and editing, using Zed with Nim extensions: https://zed.dev/docs/languages/nim
Sorry, I don't really do debuggers... I mostly step through code interactively using a REPL (INim).
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
I see comments like this fairly often and in my entire career (I'm 53) I've never had to use a debugger. For inspection of values, I write small functions and unit tests or just output to stderr in debug modes set with env vars. I've always thought that the need to use a debugger was a code smell- too much cyclomatic complexity of single functions.
Have you ever used rr though?
https://github.com/rr-debugger/rr
Does Nim not output the #line directives when compiling to C? That alone should help with the debugging experience.
My experience has been the same. I have found it much easier to write good Nim and F# code with Claide Code, than say modern Python with type hints everywhere.
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.
Nice to see more embedded language options!
oh nim nim nim nim nim, fucking nim
shoutout if you got that [reference](https://youtube.com/watch?v=Z7PH36ZAao4)