As for startup speed, note that in this round our research software engineer in the Julia Lab just brought the "first time to plot" to about 1/4 of what it was before. Julia 1.3 has a lot of these updates, and Julia 1.4 has a development sprint for bringing down the latency. I would be surprised if the common major latency issues still exist past next summer. Of course a JIT will always have some bumps compared to a pure interpreter, but Julia's compiler is definitely getting a lot smarter as to what to try and fully analyze (and what to cache)

You can ;-) The secret sauce in Julia is to use Revise.jl package. Is makes your life so much better. It observes source code changes while you are at the REPL. No need to restart everything.

How reliable is Revise.jl compared to ipython autoreload? My experience with ipython autoreload is... very poor, even though some people swear by it, so I have trust issues with this type of thing.

I use it extensively. In my experience it is very reliable. Onle once or twice in two years of using it has something strange happened with JIT compilation of functions. All I had to do to fix was restart the Julia REPL and load things in again.

+1 for this package. Total game changer.

One downside is Revise v2 actually itself has a fairly high startup cost. Best alternative is to pin it to Revise v1.

I personsally don't mind the startup too much. But I do get where people are coming from

> If you want tight feedback loops you have to figure out a way to reuse a Julia instance

I think Julia is meant to be used like Lisp:

- Step 1: Open the REPL.

- Step 2: Don't close it until you are finished (both writing and running your program).

My best guess is that people that complain about startup speed of Julia (and Emacs too for that matter) ignore step 2.

For myself, I write scripts that are part of automated analysis pipelines. So in my case (and probably others), using the REPL is mostly useful for testing code.

Julia has 0-copy numpy array interop through PyCall.jl if that's what you're asking.

It is. Thanks!

> One thing that stuck with me was the non-negligible start-up speed.

Yes! this is the biggest roadblock for me. I find python startup time unbearably long. I do not want to imagine even using julia. And this is sad because the language is orders of magnitude better (for math, at least).

If you're used to launching everything from your OS's command prompt, this is a killer. But if you get used to launching a REPL and running things from there, it's much better, because you only pay the startup latency once.

Some workflows require running scripts from the command line though

I agree and this still holds it back from being the main language in a research environment where one wants to have quick turnaround time.

On the other hand, it should work very well as a replacement for Numba. Numba already comes with a one-off jit cost, and it is much more limited in the sort of code it can speed up.