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. 
), and my impression is that Kristoffer also just figured it out as he dove in. But it’s also understandable if you don’t want to go there and instead focus on things that you’re already efficient in doing; it’s just that then you have to be prepared to wait for someone else to take that plunge or otherwise find the time to invest in it.
Maybe I should try to learn in the near future.
). I don’t think anybody is “right” or “wrong”, just that Julia users come from many different backgrounds and have quite different perspectives, so it’s helpful to understand the different perspectives in order to promote Julia to a wider adoption.