4 ms·

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 standar

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 https://nim-lang.org/docs/tut1.html

inbx0 6y ago
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.
- longstation 6y ago
  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).
planetis 6y ago
Ah debugging is very simple, just call `writeStacktrace()` (I assume you can guess what it does) It's great!
mattarm 6y ago
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.
- zubspace 6y ago
  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..
- pjmlp 6y ago
  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.
auxym 6y ago
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 https://github.com/nim-lang/RFCs/issues/300
blackrock 6y ago
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian W. Kernighan https://twitter.com/codewisdom/status/867818359840280576 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.

inbx0 6y ago

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.

longstation 6y ago
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).

planetis 6y ago

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

mattarm 6y ago

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.

zubspace 6y ago
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..
pjmlp 6y ago
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.

auxym 6y ago

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 https://github.com/nim-lang/RFCs/issues/300

blackrock 6y ago

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian W. Kernighan https://twitter.com/codewisdom/status/867818359840280576 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.