Recently I’m promoting using Julia for our group’s next project. For context, we are choosing between Python and Julia for numerical simulations and prototype modeling. I advertised Julia’s speed, and did casual demos for some language features as well as the Juno IDE. One interesting observation is, I’m mostly worried about resistance to adoption coming from the following directions: (1) JIT compilation is slow leading to slow 1st time execution (the famous “time to first plot” issue). (2) Some packages in Python are not available or not mature/stable in Julia yet. In particular, Julia native visualization packages are not as mature as matplotlib. (3) The Juno IDE is heavy in resource use and a bit slow, while other IDE choices do not have some key features. (4) Not easy and not always possible to distribute a binary executable. However, I’m surprised when I got the feedback from two colleagues who played with Julia + Juno a little bit: they mainly complained about the debugger GUI in Juno! Here I have to mention this: we are an engineering company, not a software company; except the software team, most of our engineers use Windows and write code in Matlab, Python, or VB.NET. Therefore, they are all used to the convenient debugger GUI in IDEs such as Matlab editor, PyCharm, and Visual Studio. Most have never used a command line debugger before. In my view the debugger GUI in Juno is already much more convenient than the command line debugger, but there are still some flaws. The main ones they complained about are: (1) Has to “Juno.@enter” a function. Cannot just push a button and start debugging the whole script. (2) Must switch back and forth between compilation mode vs. interpreted mode. Interpreted mode is slow, and will crash at external C calls; compilation mode can avoid these issues but may not hit a break point, and WILL NOT hit a break point set inside a function B that is called inside the function A under debug. The trick I showed them is to also set a break point inside function A where function B is called, and use compilation mode + continue to reach there quickly without crashing due to a C call e.g. in PyPlot. Once there, I can switch to interpreted mode, and continue. It will be a bit slower, but the break point inside function B will be hit. However, this trick is a bit too complicated for them. They also ask what if function B is wrapped in a big loop inside function A, and they want to observe the break point in function B being hit again and again and see what changes. If they have to switch back and forth between compilation and interpreted mode, it is rather tedious; forgetting to switch could lead to missing a break point, a very long wait, or even crashing the debugger. (3) Debugger may enter Julia’s internal code if one wants to step over macros like @time and @profiler. Also debugger support for multi-threading does not seem to be ready? (4) (This one is minor) No watch list for variables. Watching a single variable is OK but not watching several at the same time. (5) In general, the debugging experience doe not feel responsive and solid. If the debugger hangs, one always wonders if he/she did something wrong, or if it’s just because debugger is still busy executing code in the interpreted mode. I personally feel my debugging experience is acceptable, but my colleagues think there is no way they can debug something moderately large (e.g. thousands to tens of thousands lines of code with several modules) that’s written by somebody else. And some are willing to choose Python solely based on the current debugger situation. For them, visual debugger is the main tool they employ to understand other engineers’ code, since for engineers, unlike software developers, documentations for code are almost always lacking, and the original author(s) often have left for another company (silicon valley life). So reading others’ code is often like detective work, and the visual debugger is the most powerful tool - use real data as input to observe how it calculates, which logic branch it enters, and what values change, etc. I want to focus on a language’s future potential in our applications, so I’d pick Julia any day. However, it seems to me that at least in some industries, debugger GUI could become the major obstacle to adoption, and this might be hard to understand for those who write code alone, or for software guys to whom Linux style command line operation is familiar, or where code architecture is clean and documentations are good. However, as Julia is competing with Matlab, I think we also need to pay attention to the need of those engineers who are used to Windows and Matlab. :slight_smile:

Hi @jlperla, I tried Infiltrator and liked it a lot. It’s equivalent to Matlab’s “keyboard” which I am familiar with. The scenario we do need a full visual debugger is, again, not to debug one’s own code, but to understand others’ code when there is no good documentation or clear architecture. When you have a spaghetti ball of function calls and you have to follow the execution to understand what the hell is going on, and when re-architecturing the whole thing is not an option, a visual debugger is the convenient detective tool one can apply to follow through at least a few typical cases and try to understand how the code works. This happens a lot with some big projects that evolved over years. Of course a new Julia project wouldn’t be in such a sorry state, but I can understand people still want the tool to be there. :slight_smile:

[image] Zhong_Pan: The scenario we do need a full visual debugger is, again, not to debug one’s own code, but to understand others’ code when there is no good documentation or clear architecture. I am 100% with you on the end-goal of a matlab debugger. It is outstanding and I live in it with matlab. But it will only happen towards that slowly without a huge external invsetment. My goal is to figure out what is the best solution given the currently available tradeoffs. My feeling is that if Infiltrator was put into the GUI - for matlab style users - it would be a better set of tradeoffs (i.e. no stepping into functions or especially dynamic walking through a function, but running at a reasonable speed) than the current interpreter based approach which have different tradeoffs. But I am not sure…

I’m not going to promise any timeline, but we still plan to integrate the debugger into the VS Code extension at some point. We would automatically get a very good UI that way that we don’t have to maintain.

@davidanthoff Looking forward to it! I guess any improvement to JuliaInterpreter speed, as well as automatic switching between compiled mode vs. interpreted mode, etc. would still be useful in the VS Code extension, right?

Yes, whenever we get to work on this, we would just be using whatever debugger infrastructure exists at that point. What we need to do to enable this scenario in VS Code is write a debug adapter. We’ve started a little bit already, but this is not a small project, and right now we are focusing on polishing some other things in the extension.

[image] jlperla: And it effectively would need to recompile the function each time you add a breakpoint. For reference this is. It normally a problem. That is generally cheap enough. It’s only voiding (part of) compile cache. Extreme worse case scenario is it takes as long as first run time. Any action you take during to user IO only needs to fast vs human reaction time. You don’t want to recompile in your hot loop. But for setting breakpoints? No worries. MixedModeDebugger trigger a similar amount of recompilation when you set a breakpoint.

[image] jlperla: Inflitrator: everything is fast except you you can’t “step into” functions. @pfitzseb things a approach similar to MixedModeDebugger’s could be added to Infiltrator to allow this. (I’m not sure I see how to do that, exactly. But it feels right.)

[image] oxinabox: That is generally cheap enough. It’s only voiding (part of) compile cache My gut tells me you are right. Even if it is a little slow in some functions, it is due to an explicit user action. When people are exploring code, they can choose to set less breakpoints if they find it slow in a particular function. Anyways, I am someone who loves the matlab debugger, and has a good sense for how people use it for code and algorithm exploration. Given the current tradeoffs, I think mixed mode and Infiltrator likely have the tradeoffs those users would find most palatable. People will still complain until the tradeoffs disappear, but they would find it useful. Whereas I am not sure the interpreter based approach can fulfill the “explore a big codebase with an algorithm running at an acceptable speed” usecase without massive investment. It does a much better job on the “I have organized my code properly into a whole bunch of functions and want to debug one of them which failed a unit test” usecase. Useful and worth continued investment, but not one most matlab users want. Just one opinion… And without Gui integration, it is hard to know. @davidanthoff have you thought about trying one of those debuggers for vscode integration?

I haven’t looked into those, but now that I know they exist I will.

I believe that Infiltrator is less experimental and pretty robust (while mixedmode is more likely to gain cool features, but has a cassette dependency and more fragile at the moment). So worth building the UI settings to make debuggers swappable (since they have different tradeoffs) but Infiltrator is a better one to start with. @oxinabox and @pfitzseb is that fair?

Improve debugger GUI to help adoption?

Tooling Juno

Topic		Replies	Views
Debugger status and future plans? Community question , debug	122	11214	February 7, 2022
Extremely slow debugging in VS Code New to Julia question , debugging , vscode	53	3852	January 20, 2025
Debugging extremely slow Tooling question	56	10372	September 5, 2023
VSCode Julia debugger usability VS Code debug	19	3525	July 20, 2022
How do you use debuggers? Community	138	28602	September 28, 2018

Improve debugger GUI to help adoption?

Related topics