
A Julia Interpreter and Debugger - one-more-minute
https://julialang.org/blog/2019/03/debuggers
======
nathcd
> JuliaInterpreter received numerous performance enhancements, and now can run
> step-wise through code at roughly 50× its original speed. These
> optimizations reduce—but come nowhere close to eliminating—the most serious
> disadvantage of running all code in the interpreter: slow performance. It is
> hoped that the performance gap between compiled and interpreted code, which
> can be many orders of magnitude, will narrow in the coming months. However,
> the interpreter will always be slower than compiled code.

> It’s also worth noting that there are cases where the interpreter feels
> faster, at least on initial execution. Julia’s JIT compiler produces
> excellent results, but all that code-analysis takes time; there is interest
> in exploring whether running more code in the interpreter could reduce
> latency, a.k.a. the “time to first plot” problem. JuliaInterpreter is a
> potential tool for exploring that trade off, and it appears that not much
> additional work would be needed.

Oh wow, this is great. I've really enjoyed what little toying around with
Julia I've done, but it seemed just shy of feeling truly interactive to me.
But I really do love the featureset of the language, so if this gets
integrated into the language and it helps in time to interactivity, I'll
absolutely be moving some parts of my work to Julia.

~~~
Certhas
More importantly to me, Julias combination of features means code is not very
self documenting and error messages are (often) terrible.

If I need to understand what subtle assumption of DifferentialEquations I
violated stepping into the point of failure is God sent. And that's a well
documented package.

More importantly, I now can usually reason my way around. But my students can
use this to learn what goes wrong in their codes interaction.

This is a massively important step in the tooling and ecosystem.
Congratulations to the developers.

------
hawski
That's a great news! I search for a new general use (for me) language. I come
from C++ and C land. I don't like Python for bigger projects, because of it's
typing regime, performance and white space significance. So far Julia seems
nice and improvement in tooling is always welcome, because tooling is crucial
for the language survival.

A side question: How is Julia for web development? I'm not really a web
developer and my mindset is more in realms of C, shell and CGI or Go. I mean a
small to mid scale operation so SQLite integration is probably enough and
Julia has a package for that.

~~~
4thaccount
Julia's main focus is on scientific computing. Basically think of it as a
Matlab or Python + Numpy or even a C++ replacement for numeric computing.

A lot of the libraries are focused on optimization, differential equations,
statistics, matrix operations...those sorts of things. It doesn't have classes
in the way you would probably think (not really an OO language).

~~~
hawski
Go and C do not have classes either. If it's a bit comparable it would be a
plus for me. I'm mainly a C++ programmer by trade by I don't enjoy it and in
my free time I use mainly C with some shell glue and some Go.

I read that their focus is on scientific computing, but I feel that there is a
growing effort to expand Julia's use cases. Also I think that some end user
applications could gain a bit from optimized statistics or matrix operations.

~~~
Tarrosion
As far as the language goes, Julia is absolutely awesome for general purpose
work, including web development, scripting, glue language, etc.

The associated libraries are, unfortunately but understandably, less well
developed than counterparts in other languages. E.g. right now I'm happily
using AWS[Core/SQS/S3], which are highly functional community developed AWS
packages, but they're definitely less full featured than boto3. My impression
is this situation is common for a variety of web and database packages.

------
amasad
This awesome! I just created a Julia Debugger playground on Repl.it:
[https://repl.it/@amasad/julia-debug](https://repl.it/@amasad/julia-debug)
(it's a bit slow to start but then runs smoothly)

Here is a quick screencast:
[https://imgur.com/a/PXTRgHp](https://imgur.com/a/PXTRgHp)

~~~
waldir
It's really great to be able to just click a link and start playing with Julia
without installing anything! While there are other platforms offering a
similar experience, I'm glad Repl.it added Julia to its tool belt.

Just a quick note for the inattentive like me: you have to click the "Run"
button before executing the `@enter foo(20)` command.

------
xvilka
They are participating in Google Summer of Code and there are many interesting
projects in the ideas[1] list.

[1] [https://julialang.org/soc/ideas-page](https://julialang.org/soc/ideas-
page)

------
tombert
Debuggers are one of those things that I almost never use, and have a
completely unearned distaste for. Literally every single time I've used a
debugger it's been useful, but it's never something I think about using off
the cuff. Maybe I'm just an incompetent goober who spends too much time on IRC
:)

I've been getting into Julia a bit for personal projects, since I like it
better than Python, so maybe this will be a good excuse to learn how to use
debuggers more effectively.

~~~
pjmlp
I have been using debuggers since Turbo Pascal 5.0.

My experience regarding people around me that don't use them is that they
never actually bothered to learn how to use them.

Same applies to other development tools like profilers and static analysers.

I guess I was quite lucky with some of the teachers and professors that
crossed my path.

~~~
tombert
I know how to use a debugger, at least how to set a breakpoint and step
through stuff. I'm sure there are features I'm not familiar with, but I at
least understand the fundamentals.

I think part of it is that for the last 5 years , every single language I've
used with any kind of professional capacity (JavaScript, Haskell, Erlang, F#,
Clojure, Scheme) has had a REPL, so I can quickly play with and reload code,
making debuggers a bit less necessary than if I were to do a purely-compiled
language.

I definitely would benefit from learning more about performance profilers
though. You've given me an idea of reading material for the weekend.

------
register
This should be a game changer. I had tried Julia before and was disappointed
by the interactivity of the REPL because redefinition of code at runtime was
anything but easy to achieve. If it works as stated Julia REPL now should be
on par with CL's one. I'll give Julia another try!

~~~
npr11
> Revise.jl allows you to modify code and use the changes without restarting
> Julia.

Might be helpful :)
[https://timholy.github.io/Revise.jl/stable/](https://timholy.github.io/Revise.jl/stable/)

~~~
register
I tried Revise and the fact that it doesn't require you to restart Julia
doesn't mean that it allows you to change code on the fly. It means that you
don't have to close the REPL and restart it and that you don't have to
explicitly reload code. To see the effects of a change to a function invoked
in a loop you have to wait for the loop to complete and return back to the
REPL. This is not really SO interactive. In CL you see the effect of any
change immediatly at the next iteration of the loop. What Revise does is to
automatically recompile updated code by detecting changes automatically. I
hope that this interpreter brings the same level of interactivity as CL. I'll
try it for sure.

~~~
flavio81
>In CL you see the effect of any change immediatly at the next iteration of
the loop.

This. I just did this today on CL, because I needed it. I was running a long
process and can't afford to stop it.

And note that i'm using a CL compiler that compiles down to machine language,
not an interpreter.

------
saagarjha
Don't know much about Julia, but it seems like this debugger works by running
the code in an interpreter? Is there tooling around debugging compiled Julia
code as well, or is this the only way to feasibly debug Julia? It any of this
tooling standardized so it could work in say GDB or LLDB (taking advantage of
their command syntax, Python API, etc.)?

~~~
chappi42
Iirc the first attempt, Gallium, did that. I believe it was technically super
ambitious and a bit brittle maybe. It worked with Julia version 0.5. Maybe one
time Keno or someone else very capable has time to revive it, I don't know.

~~~
KenoFischer
The history here is a bit as follows. Back about four years ago, I set out to
write a debugger for Julia and while I was at it, I figured I might as well
fix all of the other things that have always bothered me about debugging. As
an example of that, it had the following features:

    
    
      - Being completely written from scratch in Julia
      - Mixed debugging between Julia and C/C++ code
      - Integration with https://github.com/mozilla/rr for time traveling debugging
      - Debugging windows programs running on a linux host under wine (and in particular even as an rr replay).
      - Zero overhead debugging by using mixed modes (DWARF based debugging generally, a much more accurate interpreter based one when possible).
      - Very precise location tracking, on an expression basis, not just a line-by-line basis
      - Multi-process debugging by riding along RPC calls, even across machine and even as separate rr recordings across machines
    

As you can tell from this feature list, that project was a bit over ambitious
and in the end failed to be a particularly useful debugger for Julia. It was
useable for a bunch of basic cases, but fairly brittle. Also, then 0.6 came
around and all of Julia's internal APIs changed and porting over the entirety
of Gallium would have been quite hard.

After 0.6 was released, I decided this wasn't working out for a Julia
debugging story and pulled out just the interpreter and UI parts from Gallium
(that package was called ASTInterpreter2.jl). This worked ok, but was lacking
a bunch of features that I never got around to implementing, because the lead
up to 1.0 required a whole bunch of compiler work that nobody else was
available to do. This work now is based on that work from 0.6, but actually
making it work nicely and paying a whole lot of attention to it that I was
never able to. I'm very happy that Tim, Kristoffer and Sebastian decided to
take this on, because I feel like my workload has only increased over the past
year ;).

I still very much want all the ambitious features from above, and we do still
have the code (and much of it is actually in use, just not for debugging) and
I'm fully expecting them to make a recurrence. However, this time around,
we'll start with a stable, usable system and gradually make it faster and add
features, rather than building an unstable system with all the features and
trying to fix it. The former approach is much better for getting usable tools
out (though sometimes the latter can lead to more interesting results in a
research setting). The other thing to note is that Julia is much more stable
now, so it's easier to keep things running without breaking every few months.

~~~
StefanKarpinski
The history of this makes me think of Gall's Law [1] which was on HN just the
other day. It will be truly awesome when we do get all of these features you
originally wanted into a standard, stable, usable Julia debugger—and I have no
doubt that we will eventually :D

[1]
[https://news.ycombinator.com/item?id=19430948](https://news.ycombinator.com/item?id=19430948)

------
teamspirit
I've been meaning to get into julia for quite some time, but I always feel
like the community is always like, "this version still needs X, when that
comes out, it'll be ready." Is this it? I guess if I had applied that logic to
anything else I would never have started on those either. Meh, maybe it's just
me.

~~~
StefanKarpinski
Yes, after this, we're done, there are no more things to do! You should start
using Julia now :)

Just kidding, there are many cool things that are in the works, including Go-
style multithreading and effortless automatic differentiation of arbitrary
code, allowing you to "machine learn" any algorithm without a complex
framework.

But that's all stuff that's not even available in most languages—now is a
great time to start using Julia:

1\. The latest stable release is 1.1—code you write now will keep working on
all 1.x releases

2\. There's excellent editor and IDE support for Julia in pretty much every
imaginable configuration

3\. There's a solid debugger with interfaces from the terminal and IDEs (and
I'm sure soon there will be many more)

~~~
sidesentists
Just as a nudge for something not really of practical importance but something
I'd like to see for other reasons: self-hosting.

~~~
oxinabox
Self-hosting leads to pain. Compiling Rust these days requires building 14
versions of Rust after building from OCAML.

I think that is worth it for Rust because I think it has good features for
building compilers. And really low level runtime-y bits.

Julia has less good features for building compilers.

But still the vast majority of the language is in Julia. Including a lot of
the code lowering.

~~~
sidesentists
Yeah, believe me, I understand the reasons for self-hosting in something like
Rust versus not self-hosting in Julia. Also the fact that Julia is almost all
Julia.

Still, the fact that it's _almost_ all Julia suggests to me it could be all
Julia, although maybe that's changed with 1.0+ releases.

Trying to think about why it matters to me, I think what it is a sense that if
you can get what Julia offers from another language that does more, it
probably is better to use that other language. So I want to see it pushed to
be more general-use. Not just for the principle, but because I think in
general there are gains to languages in doing so. E.g., my guess is that
getting Julia to be self-hosting would require certain efforts that might pay
off in other ways, or set the stage for such things.

------
h8hawk
The main problem with Juno is Atom . I really hope julia come up with better
VSCode support. Atom editor is essentially broken. They should choose VSCode
as their main editor.

~~~
chrispeel
There is no __main __editor, you chose your own. Some who like VSCode made
[1], which you could use and contribute to.

[1] [https://github.com/JuliaEditorSupport/julia-
vscode](https://github.com/JuliaEditorSupport/julia-vscode)

------
iamed2
One thing that outsiders miss when considering MATLAB is the incredible
debugging workflow. With this release and the Juno integration, we finally
have the same experience for Julia! As a developer who used to use MATLAB and
now uses Julia every day I am very excited to make use of this tool.

------
FridgeSeal
This is super cool and I’m really looking forward to giving this a go, great
work Julia team!

------
mark_l_watson
Sweet. I have been slowly learning Julia - this should help!

------
boromi
When can we expect integration with VScode. Atom is too slow on my computer.

------
AlexCoventry
I tried julia three years ago, but version skew was a huge drag. Has the
situtation improved on that front?

~~~
BlackFingolfin
Yes, the language was (intentionally) stabilized with 1.0. So version 1.1 (the
current one) is fully compatible with that, and this will remain so for the
whole 1.x series. And I expect that even 2.x won't be as bad (if at all) as
the major changes that were made during the early evolution of the language.

~~~
oxinabox
Amazingly, even packages have started to stablize. Even though a great many of
them are on there own v0.x, they are both moving towards theire 1.0 releases,
and being more careful about not breaking there v0.x releases.

------
b_tterc_p
Does this mean for loops would now be slower than vectorized ops? Excuse me if
that’s a stupid question

