4 ms·

As I member of the Rust team, I personally would like Rust to be a suitable replacement for fortran, and I suspect most Rust core contributors would feel the sa

by brson 10y ago

As I member of the Rust team, I personally would like Rust to be a suitable replacement for fortran, and I suspect most Rust core contributors would feel the same. Rust already has competitive performance so it feels like a small step to be able to fit into fortran's niche. I don't know the particular multidimensional array discussion you experienced, but evolving a language takes slow time, and meanwhile people experiment with what is possible out-of-tree, like with the ndarray library, which seems to be well respected. Right now there is a focus on SIMD in Rust, which is crucial for this domain, so there is progress being made.

luthaf 10y ago
> I don't know the particular multidimensional array discussion you experienced, but evolving a language takes slow time, and meanwhile people experiment with what is possible out-of-tree, like with the ndarray library, which seems to be well respected. A Fortran-like multidimensional library could effectively happen out of tree, but ndarray is closer to Python's numpy.ndarray than to Fortran arrays. And this means that ndarray can not support negative indexing (see here: https://github.com/bluss/rust-ndarray/issues/152 https://github.com/bluss/rust-ndarray/issues/152). I started a prototype of Fortran like array here: https://github.com/Luthaf/mudi https://github.com/Luthaf/mudi, if anyone want to look at the code or even work on this. My only problem at the time was that `Index` must always return a reference, and cannot return a new struct. From my understanding, this could be solved with the HKT/ATC work. > Right now there is a focus on SIMD in Rust, which is crucial for this domain, so there is progress being made. This is very exciting! And knowing the Rust community, we may even get a cross-platform cross-architecture SIMD library with a nice API!
- steveklabnik 10y ago
  The SIMD stuff is extremely complex. The focus for now seems to be to _not_ work on a nice API, and tackle the problems with just getting the absolute basics done in an acceptable way. Higher level stuff will come later.
Manishearth 10y ago
So in my previous life as a physics student I did talk to many physicists about why Fortran was popular (and later when I discovered Rust, discussed Rust with them). The main blocker is just that fortran has a wonderful ecosystem of scientific computing packages and you can find almost any operation you need out there. This is not true of even Matlab or Mathematica. I have often had to reimplement random algorithms in Mathematica. Fortunately mathematica gives some pretty good high-level tools, so it's not that bad, but it's still annoying. Multidimensional arrays was brought up as an issue with C/++. AIUI using macros in C++ makes it tolerable, but not great. I did ask about `arr[(1, 2, 3)]` and folks seemed okay with it. Many have used mathematica where indexing is done with double braces (`arr[[1,2,3]]`) so it isn't too bad. Implicit bounds checking was something that was frowned upon. Could even be a dealbreaker. While usually bounds checking can get elided by llvm, scientific computing does tons of indexing and the overhead might crop up in the profile. I'm not actually sure of how well this maps to the real world, and never got a chance to profile this, but it's a concern. Libraries like ndarray could turn it off but it would basically be unsafe :| ------- I did use Rust for some scientific computing. At the time, IIRC numeric types had to be more explicit, which was annoying, but that was pretty much my only issue with it (I didn't need any existing scientific libraries). I didn't know of any good visualization libraries so I would usually output to json/csv and visualize in Mathematica. But I have done the same for Fortran code; Mathematica is just awesome at visualization and analysis. I recall having access to a scientific computing cluster where the only up to date thing was ifort. It had an ancient python, and icc (IIRC it was ancient too, but I'm not sure). Had to compile a bunch of compilers myself to get my own code to run. Asked about this and apparently everyone just used fortran. Python is common in post-processing but a lot of the tools they were using were ancient or maintained by people with similarly ancient toolchains so stuff still worked on it.

by brson 10y ago

luthaf 10y ago

> I don't know the particular multidimensional array discussion you experienced, but evolving a language takes slow time, and meanwhile people experiment with what is possible out-of-tree, like with the ndarray library, which seems to be well respected. A Fortran-like multidimensional library could effectively happen out of tree, but ndarray is closer to Python's numpy.ndarray than to Fortran arrays. And this means that ndarray can not support negative indexing (see here: https://github.com/bluss/rust-ndarray/issues/152 https://github.com/bluss/rust-ndarray/issues/152). I started a prototype of Fortran like array here: https://github.com/Luthaf/mudi https://github.com/Luthaf/mudi, if anyone want to look at the code or even work on this. My only problem at the time was that `Index` must always return a reference, and cannot return a new struct. From my understanding, this could be solved with the HKT/ATC work. > Right now there is a focus on SIMD in Rust, which is crucial for this domain, so there is progress being made. This is very exciting! And knowing the Rust community, we may even get a cross-platform cross-architecture SIMD library with a nice API!

steveklabnik 10y ago
The SIMD stuff is extremely complex. The focus for now seems to be to _not_ work on a nice API, and tackle the problems with just getting the absolute basics done in an acceptable way. Higher level stuff will come later.

Manishearth 10y ago

So in my previous life as a physics student I did talk to many physicists about why Fortran was popular (and later when I discovered Rust, discussed Rust with them). The main blocker is just that fortran has a wonderful ecosystem of scientific computing packages and you can find almost any operation you need out there. This is not true of even Matlab or Mathematica. I have often had to reimplement random algorithms in Mathematica. Fortunately mathematica gives some pretty good high-level tools, so it's not that bad, but it's still annoying. Multidimensional arrays was brought up as an issue with C/++. AIUI using macros in C++ makes it tolerable, but not great. I did ask about `arr[(1, 2, 3)]` and folks seemed okay with it. Many have used mathematica where indexing is done with double braces (`arr[[1,2,3]]`) so it isn't too bad. Implicit bounds checking was something that was frowned upon. Could even be a dealbreaker. While usually bounds checking can get elided by llvm, scientific computing does tons of indexing and the overhead might crop up in the profile. I'm not actually sure of how well this maps to the real world, and never got a chance to profile this, but it's a concern. Libraries like ndarray could turn it off but it would basically be unsafe :| ------- I did use Rust for some scientific computing. At the time, IIRC numeric types had to be more explicit, which was annoying, but that was pretty much my only issue with it (I didn't need any existing scientific libraries). I didn't know of any good visualization libraries so I would usually output to json/csv and visualize in Mathematica. But I have done the same for Fortran code; Mathematica is just awesome at visualization and analysis. I recall having access to a scientific computing cluster where the only up to date thing was ifort. It had an ancient python, and icc (IIRC it was ancient too, but I'm not sure). Had to compile a bunch of compilers myself to get my own code to run. Asked about this and apparently everyone just used fortran. Python is common in post-processing but a lot of the tools they were using were ancient or maintained by people with similarly ancient toolchains so stuff still worked on it.