Live data from Hacker News

Julia adoption keeps climbing

hpcwire.com

41–50 of 309 posts

Re: Julia adoption keeps climbing

#41

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that should work intuitively sometimes doesn't, and when you get a cryptic error message, it's difficult to find relevant help online. And when you do find help, some of it is out of date because the language has changed over the past few years. - You can squeeze a lot o…

Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche. In addition to being considerably faster than python, it also has quite some innovative libraries in the area. This can also extend into machine learning, where python has been the go to language, despite its limitations. For other areas, like web programming, there is no sign of Julia replacing Python i…

It's not overtaking at all. It's seen growth in some areas.

The issue with regards to web programming/other programming is important, because sometimes it's useful to make a website/build another tool as a scientist. Python can do both easily.

Re: Julia adoption keeps climbing

#44

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that should work intuitively sometimes doesn't, and when you get a cryptic error message, it's difficult to find relevant help online. And when you do find help, some of it is out of date because the language has changed over the past few years. - You can squeeze a lot o…

I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.

Wait, why can't you use a regular jupyter notebook for julia? The "ju" in "jupyter" stands for what, then?

Re: Julia adoption keeps climbing

#45

Not until it addresses the JIT overhead.

In my tests I frequently switch between cpython, pypy and julia (depending on the libraries/task I want to perform) and I haven't found the JIT overhead to be worse than pypy on average. Count me as one of the 1-based index haters, but I do love multiple dispatch and the language in general. As a language for explorative tools and analysis is on par of python (strict preference between the two according to taste). To…

Are many scientists using PyPy though? I never saw it in use in academia even though I'd tried it out personally.

Re: Julia adoption keeps climbing

#46
Python has a battle-tested, humongous standard library, and a rich ecosystem. It is easy to learn and it's great at gluing every day stuff. Data scientists like it, engineers like it, even the cashier at Lidl likes it.

I can see how Julia may challenge Python for academic use, but challenging Python in 2021 for industrial use is no joke.

Re: Julia adoption keeps climbing

#47
post #25

> It will be important for it to be adopted as a first-class target language by CPU/GPU vendors.” I’m not sure what the Apple M1 SoC with AMX [1] means for Julia within the Apple ecosystem. [1] https://news.ycombinator.com/item?id=25801500

I'm expecting somebody to add them to LLVM soon. I'd talked to folks at Apple about that some time back, but they weren't able to tell me at the time what their plans were for adding it. That said, I am fully expecting them to just add it to LLVM themselves. If not, somebody in the community will do it. Once that's done, Julia will just pick it up.

This is interesting to hear. Thank you Keno

Re: Julia adoption keeps climbing

#49
post #40

Earlier quoted context omitted.

I second this. Python is actually starting to get significant traction in the scientific community. Depending on the field, R, Fortran and Matlab (and even C++) still have a huge lead. It's nice that Julia is getting noticed, but it's a distant blip in the radar. The sci community is really hard to move from existing battle-tested and performant libraries.

I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked…

> prototyped in Python, then ported to C++

This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite.

However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-level as Python but faster - is there a language that’s as high-level as Python but AOT-compiled?

Re: Julia adoption keeps climbing

#50

Earlier quoted context omitted.

You can call Python directly from Julia https://github.com/JuliaPy/PyCall.jl so much of the Python library ecosystem (say, matplotlib) is available to be used in Julia programs. That helps the adoption story quite a bit. You can do the number-crunching in Julia where performance counts, and then analyse and present the results using Python.

- Using Python directly is a better experience than calling Python from Julia - I've never run into unsolveable performance issues with Python So I guess I'm not in the target audience unless I just happen to be curious about a new language? That's kind of my overall point - even if Julia is a good language on its own and I work in data science, I don't have reasons to pick it over Python.

If you haven't hit a brick wall with python, it is just because you haven't run into the right problem. I was doing something that required lots of conditional operations on small matrices. The FFI into numpy's native library really bogged it down. I didn't have permission to install a compiler on that machine so I wrote it in vba in excel. It was 11x faster.
Post reply on HN