[caiocaiocaio]

Julia looked interesting to me, so I tried 1.0 after it came out. I have a oldish laptop (fine for my needs), and every time I tried to do seemingly anything, it spent ~5 minutes recompiling libraries or something. So I've been waiting newer versions that hopefully stop doing that, or for me to buy a better computer.

[anonova]

Yes, this is ones of my problems with Julia. It seems to be optimized for long runs and REPL/notebook usage.

Take, for example, a simple program that creates a line plot (https://docs.juliaplots.org/latest/tutorial/):

    using Plots
    x = 1:10
    y = rand(10)
    plot(x, y)

After installing the package, the first run has to precompile(?), and subsequent runs use the package cache. But ~25 s to create a simple plot is incredibly slow and frustrating to work with.

    $ julia --version
    julia version 1.1.1
    $ time julia plot.jl
    julia plot.jl  73.71s user 4.45s system 110% cpu 1:11.04 total
    $ time julia plot.jl
    julia plot.jl  24.41s user 0.39s system 100% cpu 24.633 total
    $ time julia plot.jl
    julia plot.jl  23.38s user 0.36s system 100% cpu 23.519 total

[improbable22]

While this probably isn't a practical way to do any real work, running it with --compile=min gives some idea what might be possible soon:

    $ julia --compile=min -e '@time (using GR; plot(rand(20)))'
      0.375836 seconds (368.83 k allocations: 20.190 MiB, 1.65% gc time)
    $ julia --compile=min -e '@time (using Plots; plot(rand(20)))'
      4.302867 seconds (6.41 M allocations: 371.485 MiB, 5.07% gc time)

[ViralBShah]

The time to second plot will be a few milliseconds, in the same process - in the same Julia session. So, while the time to first plot is frustrating, it is ok if your interactive session times are longer.

Of course, we continue to work on improving compile times. About half of the time is spent in LLVM compilation, which has actually become slower over time.

[tomrod]

What prevents the plot compilation from being pre-compiled at install?

[jebej]

The Plots package adds a significant overhead right now. Try using PyPlot (matplotlib) directly. These days you can use exactly the same syntax (dot-call) as in Python.

   $ time julia -e "using PyPlot;x=1:10;y=rand(10);plot(x,y);"
   real    0m5.676s

[SolarNet]

This is a core part of the design. It's part of why Julia is so useful for scientific computing, where one often has a large job that will require a lot of processing time, such that it is worth it to do an intensive JIT cycle every-time. And part of that is the analysis to take python-esque code and turning it into C levels of performance.

[aurelian15]

I just looked into Julia (1.1) for scientific use (simulation of very simple dynamical systems) a few days ago. I have to admit that by the end of the day I was surprisingly frustrated. I felt that type annotations were insufficient (one of the reasons to move away from Python); in particular, I didn't find a way to specify statically sized array types as you can do with Eigen, a feature that I find incredibly useful to find mistakes at compile time. Furthermore, just plotting something (using Gadfly) took about 30 seconds the first time after Julia was started and about 20 seconds every consecutive call (on a high-end workstation, mind you).

The next day I just ended up using C++/Eigen with a simple matplotlib binding [1]. The code is nearly indistinguishable from Python/Julia (except for having more verbose types where it makes sense, using "auto" otherwise), and the entire compile+run cycle takes less time for some short runs than it takes Julia to print "Hello World".

That being said, I'm not advocating for people to use C++. I would love to use Julia, and applaud the developers for their hard work and contribution to scientific computing, but as it stands right now, it doesn't seem to be the right tool for me, since I'm relying on fast editing/execution cycles.

[1] https://github.com/lava/matplotlib-cpp

[ddragon]

>since I'm relying on fast editing/execution cycles

While you can't do it from the shell very well right now (rerunning the program at each step like you would with an interpreted language), that kind of fast cycle is something very common in Julia development but with a particular REPL based workflow [1] in which you use a tool like Revise.jl [2] to automatically update the definition whenever you save a file in your project (the only restriction is that it doesn't automatically updates new type definitions) and directly interacting with the program in the REPL. This way it will only recompile what you just altered, and it's very fast to actually run the code. Other interesting tools are Rebugger.jl (debugger for the REPL) [3] and OhMyREPL (coloring for the REPL) [4], which you can add to your startup.jl to always automatically load them.

[1] https://docs.julialang.org/en/v1/manual/workflow-tips/index....

[2] https://github.com/timholy/Revise.jl

[3] https://github.com/timholy/Rebugger.jl

[4] https://github.com/KristofferC/OhMyREPL.jl

[adamnemecek]

> I didn't find a way to specify the exact size of arrays in the type as you can do with Eigen

https://github.com/JuliaArrays/StaticArrays.jl

[improbable22]

The default Array does not have a size as part of its type. There's a package StaticArrays which does this, typically faster below about 100 elements. But this isn't useful for catching mistakes before you run it, obviously.

Plotting is indeed slower than ideal, have not used Gadfly but Plots is more like 15s after restarting, then 10ms each time after. GR is faster, 5s or so the first.

[zmk_]

About Gadfly. If you were plotting it in a notebook then the default is to make it an interactive figure. In that case a lot of overhead comes from the browser trying to render it. You can explicitly invoke e.g., draw(SVG(10cm,10cm), plot(...)) to make it much faster.

[ChrisRackauckas]

The DiffEqTutorials has a tutorial which covers how to use statically-sized arrays to optimize the simulation of dynamical systems.

http://juliadiffeq.org/DiffEqTutorials.jl/html/introduction/...

[orbifold]

Julia is what happens if you let amateurs develop a compiler. The few times I’ve tried it produced gigabytes worth of stuff super slowly. The majority of packages are half backed, the only way to discover any type error is to let the program run, which coupled with multi method dispatch and hellishly slow compile times for trivial amounts of code makes the whole experience super unpleasant. Modern C++ plus some python feels more pleasant to work with (lightning fast compiles).

[pjmlp]

In case you missed, LLVM and GCC enjoy lots of contributions from amateurs.

Maybe they should stop accepting them then.

[dmix]

Amateurs developing a compiler != amateurs contributing to a compiler. Every popular project has clear project leads who guide most important decision making.

Not that I have any position on Julia

[ddragon]

While the aggressive JIT it's a core part of the current approach, it's still an implementation detail and not a property of the language design itself, and other compilation strategies are being developed, such as interpretation/less aggressive JIT for when you only want to run something simple a few times (like JuliaInterpreter.jl and the --compile=min flag), better sharing precompiled code between sessions (like PackageCompiler.jl and the variants) and possibly even AoT with reduced functionality (which will be useful for writing Julia libs for other languages and stuff like WASM).

[caiocaiocaio]

Yeah, a dev mode would be nice.

[fundamental]

Sure, though it does seem like there's still work to be done on the side of decreasing package load time since parsing/compiling/etc does not necessarily need to be done the second/third/etc time you load the same package. It's gotten better with past releases, though it still seems to have a ways to go.

[mlevental]

my bigger problem is how unstable all of the apis are. every single time i try to follow a guide/tutorial i get compilation errors because packages have shifted.

[eigenspace]

Now that 1.0 is out, APIs have stabilized a ton, even in the package ecosystem. But depending n your stability needs, packages might still be changing too fast.

I’d say for most people, there’s so much great progress and improvements happening that the breakages are well worth it.