We do statistical modeling in Python in our company. When a statistician asked for R, I said "no, but you can have Julia". He's quite happy with it, and we're planning to move some stuff over.
Julia and JuliaHub: Advancing Innovation and Growth
31–40 of 72 posts
Re: Julia and JuliaHub: Advancing Innovation and Growth
#32I'm curious how people feel about the JIT compilation time vs runtime tradeoff these days. Any good recent benchmarks?
Chapel folk did a really nice benchmark last year including Julia, where it landed pretty much right on the Pareto frontier of code size vs performance
I know that's not exactly answering your question, but you might be interested https://chapel-lang.org/ChapelCon/2024/chamberlain-clbg.pdf
Re: Julia and JuliaHub: Advancing Innovation and Growth
#33I've used, and am still using, Julia for my PhD research. It's perfect for parallel/distributed computing, and the neural network primitives are more than enough for my purposes. Anything I write in pure julia runs really, really fast, and has great profiling tools to improve performance further. Julia also integrates with python, with stuff like PythonCall.jl. I've gotten everything to work so far, but it hasn't bee…
Your last sentence applies equally to Fortran. How would you compare Julia and Fortran?
Julia is dynamically typed, has a very rich type system, powerful metaprogramming and polymorphism tools.
Julia also has an active thriving ecosystem, and an excellent package manager.
Re: Julia and JuliaHub: Advancing Innovation and Growth
#34According to Stackoverflow trends, Julia’s popularity is decreasing and very small https://trends.stackoverflow.co/?tags=julia
Julia users don't go to Stack Overflow because we have better options.
Re: Julia and JuliaHub: Advancing Innovation and Growth
#35I'm curious how people feel about the JIT compilation time vs runtime tradeoff these days. Any good recent benchmarks?
Chapel folk did a really nice benchmark last year including Julia, where it landed pretty much right on the Pareto frontier of code size vs performance I know that's not exactly answering your question, but you might be interested https://chapel-lang.org/ChapelCon/2024/chamberlain-clbg.pdf
The ~10-minute video for this talk is here, if anyone's interested in the narrative behind the slides: https://www.youtube.com/watch?v=U8KM8wv32js
Re: Julia and JuliaHub: Advancing Innovation and Growth
#36I've used, and am still using, Julia for my PhD research. It's perfect for parallel/distributed computing, and the neural network primitives are more than enough for my purposes. Anything I write in pure julia runs really, really fast, and has great profiling tools to improve performance further. Julia also integrates with python, with stuff like PythonCall.jl. I've gotten everything to work so far, but it hasn't bee…
I actually find that ecosystem for Julia is not that big of an issue for me. I guess that my specific use-case (data analysis, numerical simulations) is probably the most developed part of the ecosystem, but regarding that I find that the ecosystem is much more homogeneous than for example python - most things work with most other things (eg units or measurement uncertainties libraries work automatically with a piloting library).
Re: Julia and JuliaHub: Advancing Innovation and Growth
#37With 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 performance improvements, Python will always be a glue language. Python succeeds because the language and its tools are *EASY TO USE*. It has nothing to do with computer science sophistication or academic prowess - it humbly gets the job done and responds to feedback.
In comparison to mojo/max/modular, the julia community doesn't seem to be concerned with capturing share from python or picking off its use cases. That's the real problem. There is room for more than one winner here. However, have the people that wanted to give julia a shot already done so? I hope not because there is so much richness to their community under the hood.
Re: Julia and JuliaHub: Advancing Innovation and Growth
#38With 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 you keep a tight, purely functional core representation of your language (e.g. jaxpr’s) and decompose your autograd into two steps (forward mode and a compiler-level transpose operation) you get a system that is substantially easier to guarantee correct gradients, is much more composable, and even makes it easier to define custom gradients.
Unfortunately, Julia didn’t actually have any proper PLT or compilers people involved in the outset. This is the original sin I see as someone with an interest in autograd. I’m sure someone more focused on type theory has a more cogent criticism of their design decisions in that domain and would identify a different “original sin”.
In the end, I think they’ve made a nice MatLab alternative but there’s a hard upper bound on what they can reach.
Re: Julia and JuliaHub: Advancing Innovation and Growth
#39As someone working with it day to day, coming from around 18 years of mostly python, I wish I could say my experience has been great. I find myself constantly battling with the JIT and compilation and recompilation and waiting around all the time (sometimes 10 to 15 minutes for some large projects). Widespread macro usage makes stack traces much harder to read. Lack of formal interfaces means a lot of static checking…
Yeah, Jax with Equinox, jaxtyping, and leaning hard on python’s static typing modules + typeguard lets you pretend that you have a nice little language embedded in python. I swore off Julia a few years ago.
Re: Julia and JuliaHub: Advancing Innovation and Growth
#40Earlier quoted context omitted.
It felt to me like they wanted to be the language for ML/DL, which they haven't achieved. They clearly have been working more towards scientific stuff + ML, all the differential equations and math packages are a testament to that (as well as the pharma stuff with Puma). I'm not aware of what the vision is currently tbh
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.