That sort of thinking is what drives number-crunching people away from a language. You end up with ten different representations for matrices, and can't pass matrices from one package to another.

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?

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 :)

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

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

* lack of type-level integers

* lack of explicit SIMD on stable Rust

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.

I mean, maybe I was an outlier, but when I was in academia I wanted to have my models compute as accurately and quickly as possible, and I generally didn't have much time for or interest in the computer coding beyond the necessary implementation details required to conduct my research.

Telling me "implement an extension", then, would have made me roll my eyes and go back to fortran.

https://bluss.github.io/rust-ndarray/master/ndarray/index.ht...