2 ms·
> The point is that Julia is easier to use and faster than Python for just about any scientific task. Try to make a plot. Last time I checked, the time to firs
by geoalchimista 6y ago
> The point is that Julia is easier to use and faster than Python for just about any scientific task.
Try to make a plot. Last time I checked, the time to first plot was still a pain point of Julia.
> it's harder to use and less expressive than Julia.
I agree that Julia is more expressive because it's a Lisp in disguise. This is definitely a plus. But in practice, I don't find Python to be "harder to use." There is good consistency among the mainstream packages in terms of API. For example, if you have a NumPy function np.mean, you can assume that Pandas would have a method .mean() for the DataFrame, and Dask would have that for DaskArray as well. Not always, but things are moving toward that direction.
> I loaded a 2gb csv file the other day in Pandas, and it consumed over 40gb of ram.
Have you tried the `engine='c'` option when calling pandas.read_csv? Pretty sure there is also another option of chunking that may be useful.
- rsfern 6y agoTime to first plot is still painful even in julia 1.5, sure. But after paying that startup cost, the speed boost can be transformative in terms of the flexibility and dynamism that it buys. I've been using Pluto.jl lately, and interactive data analysis feels like way less of a burden than working in jupyter. As to harder to use, writing fast vectorized numpy code can take a lot of mental effort. For one project I ended up forcing things into this 5-D array broadcasting mess, where in julia it's way simpler to just write intuitive code that's performant without bending over backwards to avoid explicit loops. For numpy code you can "just" drop down to cython, but for pytorch you can get stuck with thinking up some clever broadcasting solution.