Julia and JuliaHub: Advancing Innovation and Growth • Hacker News Board

Re: Julia and JuliaHub: Advancing Innovation and Growth

#41

Post by tomnicholas1 » Wed, Feb 05, 2025, 7:23 PM UTC

Kalanos wrote: post #37

With some serious repositioning, I think there is still an opportunity for Julia to displace Python tools like polars/pandas/numpy, airflow, and pytorch -- with a unified ecosystem that makes it easy to transition to GPU and lead a differentiable programming revolution. They have the brain power to do it. The future of Python's main open source data science ecosystem, numfocus, does not seem bright. Despite performan…

> The future of Python's main open source data science ecosystem, numfocus, does not seem bright. Despite performance improvements, Python will always be a glue language.

Your first sentence is a scorching hot take, but I don't see how it's justified by your second sentence.

The community always understood that python is a glue language, which is why the bottleneck interfaces (with IO or between array types) are implemented in lower-level languages or ABIs. The former was originally C but often is now Rust, and Apache Arrow is a great example of the latter.

The strength of using Python is when you want to do anything beyond pure computation (e.g. networking) the rest of the world already built a package for that.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#42

Post by lagrange77 » Wed, Feb 05, 2025, 7:24 PM UTC

catgary wrote: post #40

mbauman wrote: post #18

Earlier quoted context omitted.

The key for me — as someone who has been around for a long time and is at JuliaHub — is that Julia excels most at problems that don't already have an efficient library implementation. If your work is well-served by existing libraries, great! There's no need to compete against something that's already working well. But that's frequently not the case for modeling, simulation, differential equations, and SciML.

The ODEs stuff in Julia is nice, but I think diffusers/JAX is a reasonable backbone to copy over whatever you need from there. I do think Julia is doing will in stats and has gotten some mindshare from R in that regard. But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily (especially if you want to use the GPU). I do miss Tullio, though.

> But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily

You mean in terms of the ODE stuff, Julia provides?

Re: Julia and JuliaHub: Advancing Innovation and Growth

#43

Post by catgary » Wed, Feb 05, 2025, 7:37 PM UTC

lagrange77 wrote: post #42

catgary wrote: post #40

Earlier quoted context omitted.

The ODEs stuff in Julia is nice, but I think diffusers/JAX is a reasonable backbone to copy over whatever you need from there. I do think Julia is doing will in stats and has gotten some mindshare from R in that regard. But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily (especially if you want to use the GPU). I do miss Tullio, though.

> But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily You mean in terms of the ODE stuff, Julia provides?

Diffusers is pretty well done (I think the author was basically rewriting some Julia libraries and adapting them to JAX). I can’t imagine it being too hard to adapt most SciML ODE solvers.

For simulations, JAX will choke on very “branchy” computations. But, honestly I’ve had very little success differentiating through those computations in the first place and they don’t run well on the GPU. Thus, I’m generally inclined to use wrappers around C++ (or ideally Rust) for those purposes (my use-case is usually some rigid-body dynamics style simulation).

Re: Julia and JuliaHub: Advancing Innovation and Growth

#44

Post by affinepplan » Wed, Feb 05, 2025, 7:57 PM UTC

catgary wrote: post #38

Kalanos wrote: post #37

With some serious repositioning, I think there is still an opportunity for Julia to displace Python tools like polars/pandas/numpy, airflow, and pytorch -- with a unified ecosystem that makes it easy to transition to GPU and lead a differentiable programming revolution. They have the brain power to do it. The future of Python's main open source data science ecosystem, numfocus, does not seem bright. Despite performan…

Julia has really lost the differentiable programming mindshare to JAX. I’ve spent weeks or months getting tricky gradients to work in Julia, only to have everything “just work” in JAX. The quality of the autograd is night and day, and goes down to the basic design decisions of the respective “languages” (in the sense that JAX jit compiles a subset of Python) and their intermediate representations. Fundamentally, when…

> Julia didn’t actually have any proper PLT or compilers people involved in the outset.

while I don't disagree that currently JAX outshines Julia's autodiff options in many ways, I think comments like this are 1. false 2. rude and 3. unnecessary to make your point

Re: Julia and JuliaHub: Advancing Innovation and Growth

#45

Post by catgary » Wed, Feb 05, 2025, 8:07 PM UTC

affinepplan wrote: post #44

catgary wrote: post #38

Earlier quoted context omitted.

Julia has really lost the differentiable programming mindshare to JAX. I’ve spent weeks or months getting tricky gradients to work in Julia, only to have everything “just work” in JAX. The quality of the autograd is night and day, and goes down to the basic design decisions of the respective “languages” (in the sense that JAX jit compiles a subset of Python) and their intermediate representations. Fundamentally, when…

> Julia didn’t actually have any proper PLT or compilers people involved in the outset. while I don't disagree that currently JAX outshines Julia's autodiff options in many ways, I think comments like this are 1. false 2. rude and 3. unnecessary to make your point

Julia was a scientific computing language made by scientific computing experts. They did a great job on some things, but whiffed a few major decisions early on.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#46

Post by affinepplan » Wed, Feb 05, 2025, 8:09 PM UTC

catgary wrote: post #45

affinepplan wrote: post #44

Earlier quoted context omitted.

> Julia didn’t actually have any proper PLT or compilers people involved in the outset. while I don't disagree that currently JAX outshines Julia's autodiff options in many ways, I think comments like this are 1. false 2. rude and 3. unnecessary to make your point

Julia was a scientific computing language made by scientific computing experts. They did a great job on some things, but whiffed a few major decisions early on.

It's a general purpose language made by experts in a myriad of subjects.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#47

Post by [deleted] » Wed, Feb 05, 2025, 9:02 PM UTC

catgary wrote: post #43

lagrange77 wrote: post #42

Earlier quoted context omitted.

> But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily You mean in terms of the ODE stuff, Julia provides?

Diffusers is pretty well done (I think the author was basically rewriting some Julia libraries and adapting them to JAX). I can’t imagine it being too hard to adapt most SciML ODE solvers. For simulations, JAX will choke on very “branchy” computations. But, honestly I’ve had very little success differentiating through those computations in the first place and they don’t run well on the GPU. Thus, I’m generally inclin…

[deleted]

Re: Julia and JuliaHub: Advancing Innovation and Growth

#48

Post by veqq » Wed, Feb 05, 2025, 9:11 PM UTC

joshlk wrote: post #11

According to Stackoverflow trends, Julia’s popularity is decreasing and very small https://trends.stackoverflow.co/?tags=julia

Stackoverflow's popularity's decreased a lot, many communities have entirely left.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#49

Post by pklausler » Wed, Feb 05, 2025, 9:32 PM UTC

pjmlp wrote: post #29

realo wrote: post #26

Earlier quoted context omitted.

Julia uses LLVM for its jit architecture, if I recall correctly. That makes it a good candidate for running well on ARM platforms (think embedded data processing at the edge). Not sure how well fortran does on ARM.

Fortran does quite well on almost any major CPU since 1950's, including GPUs. Actually one of the reasons CUDA won the hearts of researchers over OpenCL, is that Khronos never cared for Fortran, and even C++ was late to the party. I attended one Khronos webminar where the panel was puzzled with a question from the audience regarding Fortran support roadmap. NVidia is sponsoring the work on the LLVM Fortran frontend,…

“sponsoring” in this case means writing nearly all of it ourselves (although we’ve had lots of help from Arm and some others on specific areas like OpenMP).

Re: Julia and JuliaHub: Advancing Innovation and Growth

#50

Post by pjmlp » Wed, Feb 05, 2025, 9:46 PM UTC

pklausler wrote: post #49

pjmlp wrote: post #29

Earlier quoted context omitted.

Fortran does quite well on almost any major CPU since 1950's, including GPUs. Actually one of the reasons CUDA won the hearts of researchers over OpenCL, is that Khronos never cared for Fortran, and even C++ was late to the party. I attended one Khronos webminar where the panel was puzzled with a question from the audience regarding Fortran support roadmap. NVidia is sponsoring the work on the LLVM Fortran frontend,…

“sponsoring” in this case means writing nearly all of it ourselves (although we’ve had lots of help from Arm and some others on specific areas like OpenMP).

I see, I do follow LLVM conference talks, but not that deep.