undefined | Better HN

0 pointsCerthas5y ago0 comments

It's weird to me to see Fortran and Mathematica grouped together. :) The reality in Python, Mathematica, etc... is that you don't write your libraries in them. You delegate the ahrd work to libraries written in Fortran/C/Rust... so as soon as your research touches on new algorithms (or even just new combinations of algorithms) you are not doing pure Python anymore but will be touching systems languages.

Julia is less interactive than Python (mostly due to the just ahead of time compilation model), but can match the speed of Fortran/C/Rust etc... so in this domain it has a strong overlap with what you use the systems languages for.

Before I transitioned my group to Julia I was looking very heavily into going to Python/Rust (and Python/Numba which I spent the most time prototyping and investigating). And I can imagine that for some groups a Python/Rust hybrid would be a better fit than Julia.

For doing some data wrangling I still prefer Python for it's smooth interactivity. But, for example, Julia now has by far the most complete, flexible and all around amazing differential equations solver library in existence. This library also wraps the Fortran stalwarts like Sundials, but it's implemented entirely in Julia. There is no C/C++/etc... backend doing the heavy lifting in the background (well if you don't count LLVM at least), and the pure Julia solvers are now beating the Fortran/C++/etc... solvers pretty much across the field.

0 comments

3 comments · 1 top-level

7thaccount5y ago· 2 in thread

I get into this argument a lot on here, but it's all about ecosystems. Scientists write numerical and stats code in languages like Python, Julia, Matlab, Mathematica...etc. The Wolfram language used to code in Mathematica is decent and I never cared if my code was being run as C in the background or whatever.

The ecosystem surrounding Rust for scientific computing is pretty much non-existent outside of the box without the user doing something with FFI. Depending on the user, that might be enough or not.

I meant to include Julia in my first list, just a typo that it isn't in there.

CerthasOP5y ago

I agree about the importance of ecosystems.

But here is the thing: In the Python ecosystem I can have fast sparse matrix multiplication, or fast numba compiled functions, or fast JITed ODE solvers. But I can't use a sparse matrix library in a compiled function that gets run in a compiled ODE solver seamlessly.

So you end up in silos that can't talk to each other without losing a lot of performance. And if you only ever need to compose the fast parts in rather trivial ways, then that is entirely sufficient and it's why Python is so amazing.

But you are very wrong if you claim that scientists write Python and don't care about what's underneath. Many scientists first write a Python implementation of their new method, and then they write a CYthon implementation or whatever to actually publish the package.

And I have actual examples where new methods were not published in Python but only in Julia because the PhD student failed to get the Python code to a point where performance was reasonable.

In the end the Julia ecosystem is _very_ different from Python. Everything can and does interoperate. As heroic as Scipy is, I think Julia's ecosystem is on a completely different trajectory.

Something like https://clima.caltech.edu/ is completely unthinkable in Python/R/Matlab/Mathematica. It could maybe be done in C++.

miguelraz5y ago

Wholeheartedly agree. I've been trying to come up with a simple metric to measure the composability of a language's ecosystem, and so far the simplest that I've come up with is to find the largest 25 libraries and try to run all their "hello world's" in the same file.

Open to suggestions on a better metric.

j / k navigate · click thread line to collapse