Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia and JuliaHub: Advancing Innovation and Growth

info.juliahub.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Julia and JuliaHub: Advancing Innovation and Growth

#51

Post by catgary »

affinepplan wrote: post #46
catgary wrote: post #45

Earlier quoted context omitted.

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.

I’m sorry, but I’m going to disagree with you on that. Can you point to any of the language designers who had a background in programming language theory? The closest thing I see is Bezanson’s work on technical computing, which seems laser-focused on array programming. I don’t really see anything related to types or program transformations.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#52

Post by ted_dunning »

Bostonian wrote: post #22
jarbus wrote: post #19

I'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 adds some pretty amazing stuff with multiple dispatch and run-time compilation. What this means is that you can glue code together in ways impossible for other languages.

One example is a system that I built using three libraries. One was a C library from Postgres for geolocation, another was Uber's H3 library (also C) and a third was a Julia native library for geodesy. From Julia, I was able to extend the API of the H3 library and the Postgres library so that all three libraries would inter-operate transparently. This extension could be done without any mods to the packages I was important.

Slightly similar, if you have a magic whizbang way of looking at your data as a strange form of matrix, you can simply implement a few optimized primitive matrix operations and the standard linear algebra libraries will now use your data structure. Normal languages can't really do that.

More on that second case and the implications in the following video:

https://www.youtube.com/watch?v=kc9HwsxE1OY

Re: Julia and JuliaHub: Advancing Innovation and Growth

#53

Post by shwouchk »

jarbus wrote: post #19

I'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 prefer the smaller community of the jusia ecosystem. For one thing, when searching for issues online youre much less likely to hit spam “tutorials” or eternal september stuff.

And other peoples code is actually a pleasure to read

Re: Julia and JuliaHub: Advancing Innovation and Growth

#54

Post by Kalanos »

tomnicholas1 wrote: post #41
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 impl…

So without the two-lang problem, I think all of these low-level optimization efforts across dataframes, tensors, and distributed computing would be part of a unified ecosystem based on shared compatibility.

For example, the reason why numfocus is so great is that everything was designed to work with numpy as its underlying data structure.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#55

Post by adgjlsfhk1 »

affinepplan wrote: post #32
kayson wrote: post #27

I'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

Also if you exclude Julia's compile time (which may or may not be reasonable depending on what you're trying to measure), Julia would gain a lot in speed since almost all of these benchmarks are in the 0.5s to 10s range.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#56

Post by adgjlsfhk1 »

cbruns wrote: post #30

I am a MATLAB and Python user who has flirted with julia as a replacement. I don't love the business model of JuliaHub, which feels very similar to Mathworks in that all the cool toolboxes are gated behind a 'contact sales' or high priced license. The free 20 hours of cloud usage is a non-starter. Also it seems that by default, all JuliaHub usage is default cloud-based? on-prem and airgapped (something I need) is imp…

I don't think this is really a good comparison. Matlab is a $150 for a personal license for the language itself ($1000/year for commercial), and if you want any packages, all the packages are extra on top of that. Julia is fully open source, and has a strong open source package ecosystem (I think we're up to 10k packages by now). Juliahub provides some enterprise systems like JuliaSim, but the language itself is totally free.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#57

Post by ssivark »

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 how does one get the composability of multiple dispatch? A problem with the Python world IME is the need to reinvent everything in Jax ecosystem, in the Pytorch ecosystem, etc -- because of fundamental language limitations. This is tedious, and feels like a lot of wasted effort.

Another example: It's frustrating that Flax had to implement it's own "lifted" transformations instead of being able to just use jax transformations -- which makes it impossible to just slot a Flax model into a jax library that integrates ODEs. Equinox might be better on this front, but that means that all the models now need to be re-implemented in Equinox. The fragmentation and churn in the Python ecosystem is outrageous -- the only reason it doesn't collapse under its own weight is how much funding and manpower ML stakeholders are able to pour into the ecosystem.

Given how much the ecosystem depends on that sponsored effort, the popular frameworks will likely prioritize ML applications, and corollary use cases will be second class citizens in case of design tradeoffs. Eg: framework overheads matter less when one is trying to use large NN models -vs- when one is trying to use small models, or other parametric approaches.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#58

Post by catgary »

ssivark wrote: post #57
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 how does one get the composability of multiple dispatch? A problem with the Python world IME is the need to reinvent everything in Jax ecosystem, in the Pytorch ecosystem, etc -- because of fundamental language limitations. This is tedious, and feels like a lot of wasted effort. Another example: It's frustrating that Flax had to implement it's own "lifted" transformations instead of being able to just use jax tra…

So, I’ll admit that I’m not a fan of multiple dispatch a la Julia. I much prefer typeclasses and explicit union types. Also, I found Julia is really the worst of both worlds of garbage collected languages and manual memory management because it ostensibly has a garbage collector but you find yourself basic preallocating memory or faffing around with StaticArrays trying to figure out why memory isn’t being allocated (often it comes down to some type instability nonsense because the type system built around multiple dispatch can’t correctly type the program). At this point I’d rather just use C++ or Rust than Julia, I’m getting annoyed just thinking about the nonsense I used to deal with.

Also, IIRC, it’s not terribly difficult to use flax with equinox. It’s just a matter of storing the weight dict and model function in an equinox module. Filter_jit will correctly recognize the weights as a dynamic variable and the flax model as a static variable.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#59

Post by culebron21 »

My experience with Julia was good, and the language is convenient, however two major factors made me not use it after test projects:

1. Very scarce packages ecosystem. Like there's dataframes.jl file with poor mans implementation of Pandas.

2. Recompiling everything every time. It meant that a Julia program in some script would take ~40 seconds compiling with dataframes & some other important packages.

I think if a language is to replace Python in science, it would need to either be very fast (recompilation on every run breaks this, and running Julia in a notebook/shell is interesting, but outside of pure scientific code, it should be easier to re-run it), or it should offer ergonomics. Pandas has very rough corners, especially when you need grouping with nontrivial operations, or grouped window functions. Joins aren't easy either. Any system that makes this more ergonomic, could bite a bit off Python. But I don't see such.

Post reply on HN