4 ms·

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 surpr

by 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.
  - cb321 1y ago
    Sure! Just compile with nim c --lineDir=on or drop `lineDir=on` in your $HOME/.config/nim/nim.cfg (or per project NimScript .nims or per file foo.nim.cfg or ...) and source-level debugging with gdb on Linux works.. 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).
    - elcritch 1y ago
      Also recently Nim’s generated C code started using Itanium name mangling, which oddly has become the defacto name mangling method for C++ on Linux and other platforms. 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.
- pmarreck 1y ago
  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.
  - SJMG 1y ago
    Have you ever used rr though? https://github.com/rr-debugger/rr https://github.com/rr-debugger/rr
    - pmarreck 1y ago
      it... goes backwards in time? OK, THIS is interesting!
aryonoco 1y ago
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.
- elcritch 1y ago
  I agree, the code output for Nim with Claude and Gemini as well is pretty good. It misses some Nim idioms but generally does really well. Simple syntax with strong types helps both Nim and F#. 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 https://github.com/elcritch/sdfy 2: https://github.com/nim-lang/atlas https://github.com/nim-lang/atlas

by hugs 1y ago

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.
- cb321 1y ago
  Sure! Just compile with nim c --lineDir=on or drop `lineDir=on` in your $HOME/.config/nim/nim.cfg (or per project NimScript .nims or per file foo.nim.cfg or ...) and source-level debugging with gdb on Linux works.. 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).
  - elcritch 1y ago
    Also recently Nim’s generated C code started using Itanium name mangling, which oddly has become the defacto name mangling method for C++ on Linux and other platforms. 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.
pmarreck 1y ago
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.
- SJMG 1y ago
  Have you ever used rr though? https://github.com/rr-debugger/rr https://github.com/rr-debugger/rr
  - pmarreck 1y ago
    it... goes backwards in time? OK, THIS is interesting!

aryonoco 1y ago

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.

elcritch 1y ago
I agree, the code output for Nim with Claude and Gemini as well is pretty good. It misses some Nim idioms but generally does really well. Simple syntax with strong types helps both Nim and F#. 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 https://github.com/elcritch/sdfy 2: https://github.com/nim-lang/atlas https://github.com/nim-lang/atlas