News for hackers. Stuff that matters.
Re:The Accelerating Adoption of Julia by outlace on Tuesday October 20, 2020 @01:54PM (#24840384)
Julia as a whole still lags behind Python or Matlab (unsurprising given the age difference) but there are some packages in Julia that just steal the show compared to Python et al, such as the SciML packages and the probabilistic programming packages. I switched to Julia for Turing.jl when I was previously using Pyro. Much happier with Julia.
Re:The Accelerating Adoption of Julia by adamnemecek on Tuesday October 20, 2020 @01:56PM (#24840412)
The best thing about julia is the interop with essentially any language you can name. Want to call numpy?

using PyCall

np = pyimport("numpy")

res = np.fft.fft(rand(ComplexF64, 10))

The interop with matlab and cpp is similarly painless.

https://github.com/JuliaInterop/Cxx.jl

Re:The Accelerating Adoption of Julia by cossatot on Tuesday October 20, 2020 @02:22PM (#24840693)
I agree that this is great, but I think saying it's Julia's best attribute is underselling the language quite a bit. Personally I like how effectively it can replace those languages, at least for future projects.
Re:The Accelerating Adoption of Julia by adamnemecek on Tuesday October 20, 2020 @02:52PM (#24841029)
You are right. One of the best things.
Re:The Accelerating Adoption of Julia by ZephyrBlu on Tuesday October 20, 2020 @03:21PM (#24841349)
Why is language interop not this simple for everything?

It seems insane to me that it's this easy in Julia, yet most other languages are completely incompatible without transpiling one into the other.

Re:The Accelerating Adoption of Julia by adamnemecek on Tuesday October 20, 2020 @03:57PM (#24841736)
Magic of macros.
Re:The Accelerating Adoption of Julia by eigenspace on Tuesday October 20, 2020 @04:22PM (#24841974)
To be fair, there are no macros in that example. Just good ol polymorphism and exceptionaly hackable semantics.
Re:The Accelerating Adoption of Julia by adamnemecek on Tuesday October 20, 2020 @04:47PM (#24842225)
Pycall does rely on macros and so do essentially all the other interop packages.
Re:The Accelerating Adoption of Julia by eigenspace on Tuesday October 20, 2020 @04:52PM (#24842259)
Sure, they all provide nice macro interfaces, but nothing in the above example required those macros as far as I understand.

This is not to say macros aren't awesome.

Re:The Accelerating Adoption of Julia by adamnemecek on Tuesday October 20, 2020 @05:55PM (#24842738)
I'm pretty sure that macros are involved in the invocation of the python function.
Re:The Accelerating Adoption of Julia by ed25519FUUU on Tuesday October 20, 2020 @02:08PM (#24840538)
Why interop with a language that already solves the problems? Just use that language.
Re:The Accelerating Adoption of Julia by Enginerrrd on Tuesday October 20, 2020 @02:16PM (#24840634)
Because it's a PITA sometimes to use c++. It's easy to accidentally go out of bounds on stuff.

I've arguably got a lot more experience doing scientific programming in c++ and FORTAN, than I do in python. Yet for quick prototyping where performance is almost never an issue, I still elect to use python because it lets me wrap my head around the problem faster. I spend less time fixing stupid errors and thinking about coding and more problem thinking about the problem I really need to solve.

Julia might be even better, I've heard good things, I've just never used it though. In the scientific computing and data science world that I deal with, I'd say at least 95% of the time there's never a need to jump from a hacked together prototype to a more production level product.

Re:The Accelerating Adoption of Julia by xh-dude on Tuesday October 20, 2020 @03:57PM (#24841735)
My experience with Julia is not deep, but I’ve found it’s really nice to iterate on something that floats towards something that flies in one ecosystem. It’s not harder than Python to get the working implementation up and going - really there is a lower volume of idiosyncrasies.
Re:The Accelerating Adoption of Julia by roywiggins on Tuesday October 20, 2020 @04:33PM (#24842085)
The only annoying thing I've found is the startup time for the REPL / notebook environments, unless you keep one running all the time. Importing biggish libraries takes some time even if they're already compiled.

I ended up making a custom system image with the libraries I always use (Plots, etc) which does help on that front.

That's a fairly minor gripe, mind you. It's still great.

Re:The Accelerating Adoption of Julia by marmaduke on Tuesday October 20, 2020 @03:15PM (#24841278)
Some libraries implement i/o formats taht you'd never want to spend time implementing, but are available in Python. Nibable is an exmaple, of neuroimaging formats I never want to understand the details of, but would need to work in Julia.
Re:The Accelerating Adoption of Julia by owlie on Tuesday October 20, 2020 @05:23PM (#24842464)
Hey neat! I use Nibabel in my work! Small world. :>
Re:The Accelerating Adoption of Julia by DNF2 on Tuesday October 20, 2020 @04:05PM (#24841824)
If language X solves 9 of my 10 problems, and language Y solves the last one of my problems, I can either, A: use language X and call out to language Y to solve all my 10 problems. Or, B: use just language Y to solve 1 of my 10 problems.

You suggest alternative B?

Re:The Accelerating Adoption of Julia by adamnemecek on Tuesday October 20, 2020 @02:10PM (#24840567)
Because julia is a better language. Numpy is written in C, why use python when you can use C?
Re:The Accelerating Adoption of Julia by StreamBright on Wednesday October 21, 2020 @04:33AM (#24845891)
I do not want to use C/C++ at all. I would like to use Numpy and Pandas because those projects are essential to my workflow.
Re:The Accelerating Adoption of Julia by datanecdote on Tuesday October 20, 2020 @02:32PM (#24840815)
Re:The Accelerating Adoption of Julia by civilized on Tuesday October 20, 2020 @02:59PM (#24841117)
What is going on here?
Re:The Accelerating Adoption of Julia by datanecdote on Tuesday October 20, 2020 @03:06PM (#24841185)
Lengthy, nuanced discussion about benchmarking between Turing devs and Stan devs.
Re:The Accelerating Adoption of Julia by nextos on Tuesday October 20, 2020 @02:07PM (#24840533)
I love Julia, but I think comparing Pyro with Turing is pretty unfair.

Pyro can scale to pretty big datasets thanks to custom inference via guides. So you can do inference on pretty sophisticated models such as Deep Markov.

Whereas Turing is mostly for small or medium sized models. For learning purposes, for smaller models or for non-parametrics Turing might be a much better choice, though.

Re:The Accelerating Adoption of Julia by outlace on Tuesday October 20, 2020 @02:14PM (#24840607)
But isn’t the good scaling due to using variational inference rather than full MCMC? Turing has VI too.
Re:The Accelerating Adoption of Julia by nextos on Tuesday October 20, 2020 @05:30PM (#24842535)
Not just that. Aside from the fact that Pyro has a lot of guide tooling, you get for example (hybrid) message passing for HMMs. This is crucial to scale beyond toy data.

Within Julia, ForneyLab.jl is quite cool for non-deep state space models. I also like Turing.jl, but it has different tradeoffs.

Re:The Accelerating Adoption of Julia by marmaduke on Tuesday October 20, 2020 @03:13PM (#24841265)
the "good scaling" is due to variational inference, which turns inference problems into optimization problems, but one has to verify the variational approximation holds, etc.

In my experience, Pyro (generally variational inference) is more like a Bayesian optimization than full inference, since it will simply miss multimodality or non-Gaussian tails, etc.