Hacker News Reader

Comment by whatever1 | Hacker News Reader

Julia is the next big thing. I am always blown away by its readability and speed.

But it will take years to build a library ecosystem that can rival the python one.

Python is sufficiently readable, and with the right extension, it is sufficiently fast for vast majority of the purposes. For Julia to truly gain momentum, I think it needs a "killer app/library". However, I'm not sure what it would be that would not already be built for Python.

My personal killer app would be a significantly revamped plotting library/app. While matplotlib is great, it is fundamentally based on imaged-based plotting. The next generation of data visualization, imo, will likely be interactive. Having an interactive plotting library that allows you to produce publication-quality plots faster and simpler (think of all the time spent aligning text manually..) could be a big deal, but it could also not matter as no one else wants the same things I do.

What are your thoughts on PlotlyJS.jl? https://plotly.com/julia/

Have a look at Makie.jl[1] in Julia. I've been using it for exploring large data sets recently. Ticks your boxes. Jupyter version is image based though, as Jupyter is inherently static. You could use Pluto.jl[2] to build a reactive page.

[1] https://github.com/JuliaPlots/Makie.jl

[2] https://github.com)fonsp/Pluto.jl

Thanks for the link. Makie.jl looks interesting. I didn't find it last time I looked into Julia. I'll get it a shot at some point to see how usable it is.

That is a big part of the author's point: the library ecosystem is here for Python today. While there is a heavy penalty for anything written in Python itself, it doesn't really matter since there isn't much of a penalty once the data is passed to highly optimized libraries and those libraries allow developers to select efficient algorithms rather than implementing their own algorithms (which are likely to be less efficient).

In this thread I am seeing a number of explanations, including:

Ecosystem; mind-share; readability and engineering mind-set; history/Numpy/Matlab; teachability and academic focus.

There are also comments emphasizing the "dynamic" scientific environment and need to just pick up code left by others.

In terms of the latter, could one apparent requirement be this: The main contact should be with top-level code which at least looks like it is interpreted -- even if through compile-with-run-combined and/or memoization? Need part of the user interface, so to speak, be to hide all intermediate artifacts, even the very thought of object code and executables? That such stuff is for, say, "module creators" not primary users?

Do you think Julia will chip away at Python's marketshare, or Fortran's? I thought it was aiming to be more of a replacement for the latter, but I've never written a line of Julia in my life, so I am very uninformed.

Julia advertises itself as solving the "two-language problem". This assumes that people first write exploratory code in python or something similar, and then rewrite it in Fortran etc. So in this scenario, Julia takes marketshare from both.

Personally, I find that many Fortran codes are still used because they have been build for many years, and they can't be rewritten easily. On the other hand, new data science projects start all the time, and the transition to Julia is easy (and worth it in my opinion). That means that in my experience, Julia is mostly competing for marketshare with NumPy/SciPy/SKLearn/Pandas/R/Matlab.

Imo, it eats away at both. Julia makes it relatively easy to meet or exceed Fortran performance, but also gives you the high level abstractions and ease of use of a language like python. I think the biggest problem for Julia currently is the difficulty of AOT compilation and the lack of tiered compilation (like Java/Javscript). Making the story for either of these better would be a significant quality of life improvement for Julia, and would make it pretty much unrivaled for scientific computing in my opinion.

Remind me if anyone might, is there any story for Julia making use of existing python libraries?

If you mean whether it's possible, PyCall.jl has existed since nearly the beginning of Julia, and PythonCall.jl [1] is a more recent package for the same core functionality - calling into Python code.

[1] https://github.com/cjdoris/PythonCall.jl

Reply on news.ycombinator.com