Hacker News Reader

Comment by noobermin | Hacker News Reader

So this is interesting but I mean imagine a post comparing R to perl. Julia I think has the potential to be a general programming language but it is primarily geared towards data scientists and (more importantly) computational scientists who are stuck writing f77 (and f90 would literally be an upgrade for them). Julia has its use case at least from my vantage point as a computational person while Rust has no applicability (yet) in that domain. For example, the lack of ability to use fortran style loops mentioned in this article kinda says to anyone looking for something new, "yeah I'll stick with fortan then."

It's fun to compare things in general but the two languange concern very different areas of computing so much so that the "differences" will actually be the differences in the domains rather than the languages actually.

View on HN

Yep. I think of computational languages for stats or numerical work like (R, Python, Matlab, Mathematica, Fortran...etc), and systems languages like (C, C++, D, Rust).

I don't see a lot of crossover there. One is expected to be very interactive for analysis and the other not interactive at all and for building infrastructure more or less.

C++ and C (somewhat of an exception here) have some good numerical libraries for things like sparse matrices, but Rust did not have mature libraries for that last time I checked, but I suppose you could do some FFI stuff.

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.

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.

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++.

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.

Reply on news.ycombinator.com