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 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?
It’s not fragile, it uses Cassette in a very light way.
It is however, experimental, and may not be so maintained etc.
The experiment is mostly complete. Though other people trying it out and commenting and brenchmarking (formally or informally) is still valuable.
It is proving the concept so we can think about using it in Debugger.jl / the rest of that stack.
It directly calls into Debugger.jl to display the UI.
Which is great for in the REPL, but probably wrong for if in a GUI.
I share a bit the other users frustrations… VSCode and Juno are fantastic… …but also fantastically bugged…
For a project I had to go on Python… Spyder (but also RStudio) are inferior products… but way more stable and fast (idem for QtCreator, the other ide I know).
I know Julia, not node or js, so I can’t help in their development… but… why not an editor in Julia itself? After all, the main advantage of Julia is indeed that libraries can be write in Julia itself, lowering the distance between users and developers…
Most of both the Atom and vs-code Julia extensions are written in Julia itself. In neither case has it seemed to bring in a bunch of programmers beyond the people who started the project (in fact, the emacs Julia mode is definitely not written in Julia and currently has more contributors than both Atom.jl and LanguageServer.jl which is the heart of the vs-code extension). There’s no evidence that writing a whole editor in Julia would be any different, and I suspect you underestimate the magnitude of the undertaking. That said, if you do decide to undertake such a project, all the best to you of course. Your prior art is:
I actually wrote one using Gtk.jl, and even though there’s some nice things about it (e.g. you can directly hide UI elements from the console, hot reload code, it’s quite snappy, or has exotic completions/refactoring options) it probably has more bugs than VSCode and Juno combined, and some of those are segfaults since it’s quite low level on the Gtk side.
Just a quick update on the VS Code debugger integration: it is going to ship in v0.15 of the extension. Right now we are trying to get 0.14 out the door, but then everything is ready to have the debugger PR merged.
I’ve been using it a fair bit, and one co-worker has been using it extensively over the last week or so. While it is not perfect, it is quite usable at this point The biggest problem is probably performance, but that is something that will have to be solved in a more fundamental way in JuliaInterpreter.jl, not in the UI frontend…
In particular, if anyone could help with 
