is there a rough timeframe when this will be resolved? (is the plan julia 1.0?) I don’t think plotly is very active (examples are broken in 0.6.2), so this seems to leave only pyplot and gadfly as common and actively worked-on solutions.
I am thinking that pyplot is the main viable working plotting package at the moment that works well with data frames.
Have you tried StatPlots.jl which adds DataFrames support for Plots.jl through the @df macro? Note that the default backend for Plots.jl is GR.jl which is very mature and reliable. Instead of Plotly.jl, look at PlotlyJS.jl which is actively maintained and works well.
not yet. I have been trying to figure out what to learn first. I am getting my list from http://docs.juliaplots.org/latest/backends/ and the julia observer. I am still trying to figure out how to identify the right package to choose and recommend. maybe StatPlots is a good idea. I see it has the same author, tom breloff, as Plots.
tic(); using DataFrames; toc();
3.6s (Julia0.6.2, Windows7, SSD)
I can tell you from experience that people coming from Python will be apoplectic over this stuff.
Agree! I have used Python for about ten years. When I first use Julia0.4, I am shocked by the long starting time of Julia. Currently, the starting time of Julia is not a problem.
I am also used to the importing time now. Compared with Python, I feel the running a Julia script file at the first time takes a long time, much longer than Python.
That said, I don’t think Julia should focus on winning over people who are using Python who are happy with Python.
I think Julia also attracts the Python users. Besides the good performance illustrated on the Julia website, I am attracted by Julia mainly by some Good packages, such as Jump.
Python really is a very good scripting language, so if you really are writing scripts I still consider Python an excellent option. Certainly better than Julia in many applications and perhaps the best if only because of how much code is available for it. What Julia tries to address is the increasingly common cases where Python is radically misused, i.e. scientific computing. Don’t get me wrong, the success of Python in an application that it was never, ever designed for is a testament to its good design, but it’s nevertheless extremely unfortunate that the world has found itself in a situation where the most well-supported option for scientific computing is basically an IT tool (again, admittedly a very good one). Once Julia has seen some compile-time improvements, in particular full-blown caching, it will be able to replace Python in many scripting situations as well, but Python will always be the better choice in those cases where you need to run a short, simple script very quickly and be absolutely sure that no time is “wasted” on compiling.
This goes to my point about attracting users who are unhappy with Python. If the benefits of (the very wonderful) JuMP matter to you, you probably fall into that group somehow, as you were probably running into the rather surprising limitations of the not-very-good optimization API’s that are available for Python.