If the numerics people can't agree on something, throwing the decision over to the core Rust folks is unlikely to result in something better.

So, the question still stands: What in Rust prevents an ambitious number cruncher with good design taste from adding the appropriate pieces to the language?

Fortran has 1st class many-dimensional arrays; can you really do that efficiently (as in "works great with a loop nest optimizer/LNO" and "has pretty syntax" and "there's one way to do it") as a Rust extension? C++ says "NOOOOOOO!!!" I don't know Rust well enough to answer the question.

You can do `arr[(1,2,3)]` in Rust (not pretty, but ok). Assuming you've marked the indexers as inline, LLVM should be able to optimize it pretty well. If it doesn't, optimizations can be added.

Rust can't enforce "one way to do it" since this would be done as a library. Currently there's only one library offering this (ndarray), so in a sense there's only one way to do it :)

What does arr[(1,2,3)] have to do with what I asked for? The code that I write for my personal scientific stuff (numerical hydrodynamics) needs loop jamming/fusion and splitting, SIMD without having to use any special notation, and other stuff which is typically provided by compiler LNO. I happen to have interchanged loops in my code, but if I goofed that up, it'd be nice for the compiler to do it for me.

No array slices needed. Plain Fortran 77 notation provides what I need.

> What does arr[(1,2,3)] have to do with what I asked for

"has pretty syntax", was just showing what the syntax would look like in Rust.

LLVM autovectorizes, and does many loop optimizations. I suspect LNO exists, but if it doesn't there's nothing preventing it from being added afaict.

Was mostly explaining what the status of this in Rust is. It's not awesome, but not horrible either.

Thanks for trying to be helpful. The place where C and C++ goes wrong is multi-dimensional arrays. Some googling tells me that narray gives Rust syntax like foo[[1,2,3]] for a 3 dimensional array. I have no guess if this optimizes well or not.

It will compile down to `foo[1][2][3]` and get optimized the same way. Rust additionally does hint a lot more about aliasability to LLVM (everything is restrict by default, basically), so there probably is more scope for optimization here.

I'm not an expert in that domain, but to my mind, the two big things are

* lack of type-level integers

* lack of explicit SIMD on stable Rust

This is already true in the Fortran world. When I was a student I was working with some condensed matter physics software and there was all kinds of madness with flipping conventions in there.

And Rust doesn't have ten different ways to do n-dimensional arrays. There's one major library out there (ndarray). I just learned about a second (https://github.com/Luthaf/mudi) which seems to use the same conventions.

There are multiple ways to do matrices, but these are in graphics-oriented libraries.

Well, it can work if one package gets dominant - e.g. the Python ecosystem works quite well with having all this outside of core language in the numpy package.

But that happening is just as likely as the fragmentation that exists in C++. Getting OpenCV to play nice with Eigen can be a hassle.