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

61–70 of 72 posts

Re: Julia and JuliaHub: Advancing Innovation and Growth

#61

Post by xgdgsc »

culebron21 wrote: post #59

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 l…

Using https://julialang.github.io/PrecompileTools.jl/stable/ to avoid recompiling everytime is pretty convenient now. And there will be https://jbytecode.github.io/juliac/ to build small binaries. I had some good experiences with https://github.com/sl-solution/InMemoryDatasets.jl and DuckDB.jl when DF.jl wasn' t performing well.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#62

Post by leephillips »

SirHumphrey wrote: post #36
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 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 pilot…

As you probably know, that almost magical interworking of libraries is a consequence of Julia’s multiple dispatch and type system:

https://arstechnica.com/science/2020/10/the-unreasonable-eff...

Re: Julia and JuliaHub: Advancing Innovation and Growth

#63

Post by leephillips »

realo wrote: post #26
Bostonian wrote: post #22

Earlier quoted context omitted.

Your last sentence applies equally to Fortran. How would you compare Julia and Fortran?

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.

And because it runs on arm (there are official arm binaries at julialang.org) you can run Julia on your phone:

https://bsky.app/profile/badphysicist.bsky.social/post/3lhfm...

Re: Julia and JuliaHub: Advancing Innovation and Growth

#64

Post by nsajko »

tmvphil wrote: post #23

As 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…

> Pkg.jl is also not great, version compatibility is kind of tacked on and has odd behavior.

Huh? I think Pkg is very good as far as package managers go, exceptionally so. What specifically is your issue with it?

Re: Julia and JuliaHub: Advancing Innovation and Growth

#65

Post by nsajko »

culebron21 wrote: post #59

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 l…

> Recompiling everything every time.

> recompilation on every run breaks this

Your comment is exceedingly misleading. Whether and when Julia code gets compiled is up to the user.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#66

Post by nsajko »

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.

> whiffed a few major decisions early on

Anything particular in mind?

Re: Julia and JuliaHub: Advancing Innovation and Growth

#67

Post by dizk12 »

culebron21 wrote: post #59

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 l…

I think the Tidier.jl has made data in julia quite nice. TidierData leverages Dataframes.jl on the backend but with tidyverse syntax, and TidierDB.jl recreates python's ibis and Rs dbplyr. TidierDB (DuckDB is the main backend, but supports 11 other DB backends) also enables grouped window functions quite smoothly as well as joins and non equijoins.

https://github.com/TidierOrg/TidierDB.jl https://github.com/TidierOrg/TidierData.jl

of note i am biased as a tidier contributor and author of tidierdb.jl but hopefully you might be willing to give it a try.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#68

Post by patrick451 »

nsajko wrote: post #66
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.

> whiffed a few major decisions early on Anything particular in mind?

The always on jit was a big mistep (IMO, the opt-in torchscript model is much better). I tried a julia a few times and it was just too slow to be usable for anything remotely exploratory. Every year or so, I'd read "TTFP has been improved", so I'd try again and it was still slow as mollasas in siberia. I suspect a lot of people had that experience and will be hard pressed to give julia a real shot at this point, even it it does/has fix the problem.

Re: Julia and JuliaHub: Advancing Innovation and Growth

#69

Post by SirHumphrey »

leephillips wrote: post #62
SirHumphrey wrote: post #36

Earlier quoted context omitted.

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 pilot…

As you probably know, that almost magical interworking of libraries is a consequence of Julia’s multiple dispatch and type system: https://arstechnica.com/science/2020/10/the-unreasonable-eff...

Yes, it's a wonderful language for scientific computing - mostly by the venture of being designed from the ground up for this role, and not retroactively ported in (like python).

Re: Julia and JuliaHub: Advancing Innovation and Growth

#70

Post by catgary »

nsajko wrote: post #66
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.

> whiffed a few major decisions early on Anything particular in mind?

In general, I’d say there’s too much superficial flexibility but not enough control.

- I wrote this elsewhere: I find their approach to memory management/mutable arrays really hits the worst of both worlds (manual memory management and garbage collection). You end up trying to preallocate memory but don’t actually have control over memory allocations. I find the dynamic type system exacerbates this.

- It’s a very big language, even in the IR. So proper program transforms like mapping functions or autograd are quite difficult to implement.

- Static compilation is really hard, which makes it a non-starter for a lot of domains where it could have made inroads (robotics, games, etc).

Post reply on HN