Hello,
I'm a data scientist and my day to day work is mostly concerned with developing deep learning systems.
Despite the popularity of Python in this area I'm looking for alternatives because of its weak typing and the very mixed native speed. After some experiments with FSharp and Rust I stumbled over links to Nim4UE during a coffee break (which is totally awesome!) and remembered that I did some work with Nim years ago.
To make a long story short - I love it!
The non intrusive, minimalist style, the nice syntax which is not drowning everything in curly braces, the fast compile and even more execution speed and the sufficiently strong typing are exactly what I've been looking for. I really like Rust but getting to the point where I'm productive enough will take some time. FSharp is also great but I don't want to baggage of .NET for my applications.
The one thing that really holds me back at the moment is the state of tooling in Nim (and not the lack of packages!) - and especially the need for a working debugger (including inspection of deeply nested structures without printf debugging, correctly demangled variable names on any scope etc.).
My experiments are limited to CLion and VSCode but from my research this seem to be the best options and I think I have followed most documents and tutorials to get this to the best possible result - which is quite disappointing.
This aspect may not be obvious if you are already a Nim expert - debuggers are an important part to learn a programming language.
If I learn a new programming language, I make many assumptions about the state the execution will produce up to a certain point which are often wrong. A very "strong" type system may reduce this but I think many still learn from reviewing what is really happening in a debugger - or to a lesser degree in a REPL or notebook type interface.
If I compare my progress in Rust with Nim I have to conclude that the advantages of Nim are mostly offset by excellent tooling in Rust like the rust analyzer and the debugging suport in CLion or VSCode.
I tried to find out about initiatives to improve Nim debugging support and I'm willing to help but I didn't find much. If you have better insight - do you know if better debugging tools are in development or planned?
Many thanks for you comments in advance
If I compare my progress in Rust with Nim I have to conclude that the advantages of Nim are mostly offset by excellent tooling in Rust like the rust analyzer and the debugging suport in CLion or VSCode.
The tooling in Rust for these things are excellent. However for me I find Nim’s expressiveness and ability to let me focus on the program logic to be way more valuable. Though I rarely or never use a debugger as a few well placed print statements let me understand the program state more quickly.
That said I think it’d be great to have better debugger tooling as well. There used to be some work on debuggers a while back? Perhaps with ARC in place it’d be a good time to revisit the GDB/LLDB integrations? The name mangling in Nim is straightforward. Even cooler would be rr integration! Unfortunately VSCode libraries give me a headache.
Alas I don’t have time to work on these things, but I believe Nim’s tooling just need a few more hands overall. I don’t believe it requires huge initiatives like Rust since Nim is often much easier to integrate into things.
I have been working on improving bits of c2nim and now it’s able to import large swaths of Ros2 headers. It’s fun to get things like it more polished. I also added a PR to help with CMake but integration. Don’t underestimate lots of people doing little bits!
It would be nice if anyone who has knowledge on this could post links to old efforts or at least a breakdown of what is possible and what next steps could be taken.
I think if there isn’t available expertise or interest at the moment in Working on this. Maybe for now improvements to the lsp support and error messages could help
I'd have to agree that tooling is the bottleneck to greater adoption for Nim -- more so than any language feature coming in 2.0 IMHO.
I want to do my part and not just complain. Maybe some day my Nim-foo will be good enough to contribute directly, but until then I'm opening to sponsoring a concerted effort to make VSCode debugging as seamless as it is for Rust and other languages.
Honestly I'm not sure what this looks like and I'm open to ideas. But I suspect there's low hanging fruit in this area and a little bit of funding could tip the incentives toward having this sooner rather than later.
Aside: I wonder if an effort to make the LLVM backend "complete" for all platforms would be a shortcut to good debugging, with other benefits. lldb-vscode plugin already works great for Rust and Julia.
Unfortunately that script never worked for me, at least on windows.
I agree with the sentiment of many in this thread. IMHO the tooling (and specially the debugging) situation is one of the biggest things limiting the adoption of nim.
In an ideal scenario, you should just be able to add a breakpoint in VS Code, run your code in debug mode, and once the breakpoint were hit, start stepping through your code, viewing the values of your (unmangled) variables in the VS Code debugger.
https://marketplace.visualstudio.com/items?itemName=geddski.macros
"macros": {
"runToNextLine": [
"editor.debug.action.toggleBreakpoint",
"cursorDown",
"editor.debug.action.toggleBreakpoint",
"workbench.action.debug.continue",
]
}
https://github.com/saem/vscode-nim/issues/59 https://www.reddit.com/r/nim/comments/lhaaa6/debugging_support_formatters_for_lldb_in_vscode/
IMPORTANT: These demanglers currently only work when using the (soon-to-be-legacy) --mm:refc memory manager.
It's certainly not ideal that the best debugging experience is obtained by copy-pasting some python code from Reddit. FWIW, there's no fundamental reason why this can't all be more streamlined with some updates to the VSCode plugin for Nim.