2 ms·

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, Mathem

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.

Certhas 5y 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/ https://clima.caltech.edu/ is completely unthinkable in Python/R/Matlab/Mathematica. It could maybe be done in C++.
- miguelraz 5y 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.

Certhas 5y 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/ https://clima.caltech.edu/ is completely unthinkable in Python/R/Matlab/Mathematica. It could maybe be done in C++.

miguelraz 5y 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.