Hacker News new | past | comments | ask | show | jobs | submit login

"Why Does Julia Work So Well?

There is an obvious reason to choose Julia:

    it's faster than other scripting languages, allowing 
    you to have the rapid development of Python/MATLAB/R 
    while producing code that is as fast as C/Fortran"

yet the startup time remains slower...

Also if you have any need to generate plots & graphs - RIP Julia. I was excited to try Julia, since it seemed to integrate some of the best features of each MATLAB, R, and Python. I was truly disappointed to discover that Julia would take minutes to render the exact same plots I was generating in Octave almost instantly.

There's PackageCompiler[0] which allows to precompile the packages you need for work into a system image. This means avoiding precompilation in the REPL every time you start up Julia. That's if you start with the custom system image.

However, it's a community effort and is somewhat non-trivial to get up and running with. Once Julia gets better precompilation/binary packaging support, common workflows like plotting will improve dramatically.

[0]: https://github.com/JuliaLang/PackageCompiler.jl

to be fair, that typically only happens the first time you make your graph; replots are typically lightning fast. but this was a major frustration for me, I haven't had occasion to use it more recently, but I understand maybe things are a bit better for graphing in julialand in the last few months?

I thought it had got better, but also I've just adjusted to work around it. Here are some timings today, Julia 1.1, cold start to first plot:

    $ julia -e '@time (using GR; plot(rand(20)))'
      3.931433 seconds (10.38 M allocations: 521.292 MiB, 6.44% gc time)
    $ julia -e '@time (using Plots; plot(rand(20)))'
     19.498644 seconds (57.26 M allocations: 2.844 GiB, 8.07% gc time)
Running with less compilation:

    $ 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)
But, as you say, it's much much quicker once started, like 1-5ms per plot.

4.3 seconds seems great. I remember when it felt like a minute or two.

I had almost the opposite experience lately. I started doing some data analysis in Python/NumPy/Matplotlib because I figured it was mostly plotting and would be quicker in Python. It was excruciatingly slow. Partly due to wanting hidpi plots on my Mac. After switching to over to Julia, the new plots package has been complete enough to handle most use cases and only takes <5s to complete after warmup compared to matplotlib’s 30s+ in many cases. Nice benefit is that Julia types shortened up my data cleaning code significantly too. My favorite Julia plots combo has been gr in Jupiter notebooks.

this is not really an issue, as long as you ignore the julia plotting capabilities; which should have never been there anyway. You can easily dump your numbers (and functions) on a text file and gnuplot them.

Uhh no. I do a lot of data analysis and if I have to dump stuff into text files every time I want to visualize something quickly then I'm going to go mental.

Simple plots take a fraction of a second in Python/R/Matlab. I feel like many people don't realize how crucial this is. Sub-second plotting makes working with data interactive. If it takes more than 5 seconds to produce simple plots, that's no longer interactive. Imagine if your debugger took half a minute to show you the value of a variable while trying to find a complex bug. You'd start pulling your hair out.

If in Julia it takes me half a minute at least (dumping to text file, reading it in somewhere else and then plotting it), Julia is going to remain firmly in the "check this language again in 2 years time if the plotting story has become sensible yet".

It would be great if it were quicker. But right now, interactive use is pretty good, like 5ms for a simple plot. It's calling julia from the command line, and thus starting cold, which is more than 5s.

That is just a really terrible way to do things and I have no idea why you would excuse it like that. Typical workflow if you use the Plots.jl package is to wait half a minute for the package to load in the REPL and then stay in the same REPL for your workflow so that you won't have to reload the package.

What I do is wait one second for the RCall.jl package to load and then use R's ggplot2 library to plot. Works really well, especially since I am really familiar with ggplot2.

I do not use the REPL, I call julia scripts from elsewhere, and then I want to recover the data out of julia, and text files are perfectly appropriate (a few thousand numbers). Then julia plotting capabilities are suboptimal with respect to specialized plotting software like gnuplot. I would really prefer if julia did not have any plotting stuff.

That's not typical workflow for the majority of data scientists. And saying you prefer Julia not have any plotting stuff sounds really really dumb to be frank.

Agreed. As a data scientist myself, I can't imagine Julia getting much "mindshare" among us with the JIT experience it has. Perhaps we're not the real target audience for Julia? But if that's the case then adoption will likely be slow, and limited to only very niche applications and roles. For Julia to really become the next big thing (and solve the damn two language problem), it needs to be an effective solution for data scientists and machine learning engineers--and right now, it just isn't.

I do machine learning and computer vision in python, statistical analysis, plotting, and anything to do with dataframes in R, and computational stuff, network science, and almost everything else in julia. I would like to switch my data analysis stuff to julia but waiting for libraries and functions to load is just too frustrating when I'm doing things interactively. I'm hoping Julia will have a good machine learning, computer vision, and data science environment in the future and it is looking like it will. But for now, it is not an easy environment to work with in these applications and you'd need some fairly specific needs to justifiably use Julia here. But the thing is that when you do have relatively esoteric things to do in these applications, it is much easier to do them in Julia.

Not a data scientist, sorry, just a mathematician

Also pretty much into the unix philosophy whereby tools should do only one thing and do it well.

Startup feels instant to me. Perhaps you are talking about precompilation. In that case, it’s insignificant for most computationally intensive applications.

I don't know the difference between startup and precompilation, and I do not really care, but if I launch a julia script from the command line it is unbearably slow for no apparent reason. Octave, on the other hand, launches instantly and starts making computations.

This is understandable, because julia is not intended to be used that way. You are supposed to "live" inside the repl. However, I prefer tools that are flexible enough that can be used comfortably in non-intended ways.

That’s compilation time. Currently yeah, it’s not fantastic, but I believe that’s being actively worked on.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact