Comment by zubspace | Hacker News Reader

Comment by zubspace | Hacker News Reader

I've used Nin for this years advent-of-code challenge. Never used Nim before but there are some great tutorials [1].

It's a nice language with a great standard library. Implicit static typing is great after a bit of getting used to. Some things like tuples or "Object Variants" are fun to use.

The only thing I'm missing is strong debugging support. You can use GDB and there is even some basic support for debugging in VSCode (through gdb behind the scenes). But most of the time I had to fall back to simple "echo" debugging because names were sometimes mangled, variables were not displayed or lines in nim did not correspond with lines in the final output, making debugging a chore. Unfortunately someone once started to write an embedded debugger (ENDB) for all platforms, but development stopped.

What's your opinion on this? In some way I would love to use Nim more in the future, but I'm afraid, that the larger the codebase gets, the more I'd suffer just because of debugging...

[1] https://nim-lang.org/docs/tut1.html

I wouldn't consider interactive step debugging an essential feature in large programs. My experience with C++ is that once program becomes "large" or makes enough use of threads, gdb falls over anyway and you're stuck with logging and "print" debugging anyway.

This largely depends in the IDE. The thing is, that a language like Nim is 'competing' with other languages like Java, C# or Python where interactive debugging is a given. I would highly prefer a language which compiles down to C code, but it's hard to give up an IDE like Visual Studio or Eclipse.

I know that many strong developers do not care that much about debugging or can use GDB without thinking. But unfortunately I'm not one of them. And I fear that Nim will stay a niche language because of that..

Sorry but that is just more an example of lack of knowledge of gdb capabilities than anything else.

Not only there are graphical frontends that provide that kind of information, gdb supports scripting and tracepoints.

There's definitely some talk in the community on improving dev tooling as a logical next step to improve adoption, eg: https://github.com/nim-lang/RFCs/issues/300

I'm wondering if the JS compile target could be used for debugging, at least in cases where it's the general logic of the app you want to debug and not some native code -specific bug. JS already has pretty good debugger story for VSCode & other editors, that has been tried and tested with other languages that compile to JavaScript. If Nim can output good source maps, the JS debuggers should pretty much just work.

I think this is a very good idea but it may depend on what you are doing. For example, if you are using Nim to talk to some C library, I believe you won't be able to compile the C part into JS for debugging (even if you are not debugging the C part of course).

Ah debugging is very simple, just call `writeStacktrace()` (I assume you can guess what it does) It's great!

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian W. Kernighan

https://twitter.com/codewisdom/status/867818359840280576

Sometimes I think if you’re spending too much time in a debugger, you’re already lost. Your program is doing something that you didn’t correctly plan for, or build tolerances to handle gracefully.

And if you’re using a debugger to fiddle with variable manipulation at that level, then you’ll probably just make your program even more unstable.

But granted, sometimes you do need a debugger, when you’re using someone else’s library.

Reply on news.ycombinator.com