As a general comment, since this is a pet peeve of mine: There’s a difference between a “debugger” and a “tool for finding/fixing bugs” (a “de-bugger”). This distinction tends to get lost in many discussions, but it’s important. Julia has pretty good tools for de-bugging. @show, @info, Infiltrator, etc. And AI tools can further help with that. But a Debugger is a very specific type of software that allows to run a program with breakpoints, and when it hits a breakpoint, continue to step through (step-in and step-over) the code, and to inspect the local variables in every frame. A good debugger also allows changing variables, and to step up to explore different code paths.
The primary use of a Debugger isn’t necessarily to identify bugs, it’s to understand control flow. If you have a large code base, you want to be able to run an “experiment” and follow the exact code path that it takes. This is all the more important in Julia with multiple dispatch, because it is impossible to know from reading the source code which method a particular line will call. Even if somehow you knew the types of all variables, you can’t know whether some indirect dependency might define a method that you don’t know about. There’s which of course, but sprinkling in which statements in combination with print-debugging` is not a great experience.
There isn’t really a substitute for a good debugger for diving into unfamiliar code. The only debugger we have in Julia is Debugger.jl, and it’s not in great shape, with the difficulties of switching between compiled and interpreted code.