I am a big fan of Julia as a programming language, but the lack of a decent debugger keeps turning me away every time I seriously consider changing to it.
Now last time I tested the debugging environment out was last summer, and I haven’t really done anything with Julia since or kept up on any potential updates.
So I’m writing this, wondering whether the debugging environment have changed in the last year or so? (My own search didn’t reveal anything, and I didn’t see anything in the Juliacon presentations this year about it either) Or whether there is any future plans for making an IDE with full debugging?
What I am looking for is an IDE environment like: Pycharm, visual studio, matlab or delphi, which are all excellent in their own way.
For me programming without a debugger is like going back to the dark ages of print random print statements scattered around a Fortran code, but yeah I guess everyone does things differently.
I had seen the first link, but not the Visual Studio one, which seems promising!
From what I can read, the debugger is still not in a place where it would be workable for heavy/large projects, but at least it seems like something is happening.
I will check back again in a few months on that and hopefully I can start using Julia seriously at some point in the near future.
I do agree with your statements to some extent, which is also why I keep coming back to Julia. But whenever I try to program anything serious in Julia I get frustrated by the amount of time and effort the debugging phase takes compared to all the other languages/IDEs I’m used to.
My usual debugging approach is to run something in debugging mode (which runs at basically the same speed as normal), and wait for it to crash, and then go in and investigate the stack, and go back through the stack and check the status of various parameters going into each function in the stack to determine where exactly things went wrong, all in the same session. Now I know that is a lot to expect from an IDE, but at this point I just can’t see myself ever doing without it in any language I change to.
You should give the REPL based development style of julia a bit more of a chance. It’s more akin to command line tools like gcc and gdb, but with super powers.
I’ve found Debugger.jl is pretty good when I need it. Very similar to gdb. I’d say as good as gdb. I’m thinking you are more interested in the IDE style debugger though.
I haven’t tested this recently (since I cannot use Julia at work), but I had the impression that the Julia debugger(s) were pretty much fully featured. What’s still missing? Performance?
The REPL style is very similar to Pythons Spyder approach, and I must admit I don’t like either of those styles.
I find they are fine when I’m dealing with simple projects, but when my code starts growing I find it impossible to debug.
The thing that killed it for me last summer was when I was trying to use it to implement a neural network through Flux running on sparse matrices, and the debugger would either crash, not stop on breakpoints, or never reach the breakpoint when I scaled it up (due to it being 10-100s of times slower than normal), and after a week I ended up going back to pytorch/pycharm.
And the scenario I described above where I don’t set breakpoints, but just let it run and wait for it to crash and then debug from the crashsite, would be completely impossible.
If that happens to me it typically means I should refactor to have less internal program state. I’m a fan of functional programming, which goes very will with REPL based dev.
However, from the little machine learning I’ve done, I can see that having complex program state is the norm. Also you are always dealing with very large amounts of data, which makes the slow debugger a problem. I feel your pain!
If performance while debugging is your main objection to Debugger.jl and similar things built on JuliaInterpreter.jl, you should give Infilitrator.jl a try. I haven’t used it myself, but my understanding is that the whole point is being able to set a breakpoint with negligible performance impact.
I think why you’re seeing less people talk about debugging Julia this year compared to in the past is because it’s in a state where it’s more than sufficient for most people’s usecases. But that could be a wrong impression given that I don’t often use debuggers myself.
I recently used the Debugger in VS Code and it worked very nicely for me (similar to the PyCharm debugger).
The lower performance due to usage of the interpreter was not an issue in my use-case, but I see your point.
There is a (currently experimental) debugger compiled mode which should solve this issue, but it does not fully support breakpoints yet.
I feel similarly about debuggers, and I will briefly explain why.
IMO the best way to structure Julia code is to write short, simple functions that do (ideally) one thing, combine them using multiple dispatch, and carefully unit test pieces. Unit tests should reveal bugs well before production.
There are languages where the prevalent style favors large, monolithic functions. These are very hard to test extensively because with more complex code, the number of possible combinations of corner cases increases exponentially, so there are always some dark corners. The common practice in these languages is to wait for an error or a nonsensical result, at which point one turns to the debugger and tries to figure it out.
This is problematic because for each error you notice, there are typically many that go unnoticed because the program does not error and the results look OK-ish (within a factor of 2 of the other papers, or maybe even novel just because of a calculation error, etc). This is problematic in all fields, but especially in scientific computing.
People who say that they don’t really need a debugger don’t write perfect code either, but catch a lot of bugs with better code organization and unit testing, and of course the occasional @show.
I often use debuggers to familiarize myself with a code base. The ‘many short functions’ style favored in Julia often makes the code flow difficult to follow — which methods (and functions) are actually being called?! Stepping in and out of functions with an interactive debugger is great for understanding what’s going on.
Extensive use of tests is probably a great idea, but would be a big change for me.
It sounds like tue’s main objection against the VSCode + Debugger approach is speed.
From what I read, compiled mode is meant to address the speed issue.
I am curious how this is working in practice for those who have tried it with larger projects.
(I come from Matlab where keyboard was my best friend. But since switching to Julia I have barely touched debuggers.)
I haven’t tried out the VSCode yet, I just read what was posted about it, and the problems people were having with it, but once I next change to a new project or when I have time, I will likely try it out.
What I am looking for in a debugging environment is something that allows me to work fast and efficiently. That means a debugger that is: fast, reliable, where I can start the debugging of my code in seconds, insert breakpoints with a single click, analyse the stack when an error is encountered, and easily step forward/into code.
Furthermore the debugger should ideally be able to handle both code running on CPU and GPU, since all my work these days involves machine learning.
As an example, my current project, involves coding up a neural network similar to BERT, with about 500 M parameters, that will be training on on about 2 TB of genetic data for a few weeks.
I think why you’re seeing less people talk about debugging Julia this year compared to in the past is because it’s in a state where it’s more than sufficient for most people’s usecases. But that could be a wrong impression given that I don’t often use debuggers myself.
Considering that so far none of the people who have commented on this thread are saying they regularly use a debugger in Julia that work well, I doubt that is the case. It seems like most Julia programmers just like working with the REPL and without a debugger.
But I do wonder how many people are, like me, staying away from Julia because of this problem.