This is to continue the discussion started by @leonardo in the effects system thread, which I think deserves more thought than fits in a quick OT:
As someone who also works on scientific computations, I can totally understand this perception/frustration. I think it ultimately boils down to several mutually related factors:
- The current population of Rust designers and users
- The design and evolution philosophy of the Rust language
When it comes to population, I hope I will surprise no one by saying that the current Rust community is not heavily focused on number crunching. From my totally biased view of the u.r.l.o discussion topics, I get the impression that the community of Rust users is currently largely focused on…
- Web development (mainly back-end, but with growing front-end interest)
- System infrastructure (CLI tools, multimedia libraries, or more radically embedded/OSdeving)
- Game development (and more generally interactive GPU-intensive programs)
The composition of the user base naturally impacts the focus of the language’s development in every area: which features are requested, how likely each feature is to be welcome, who is ready to design and implement stuff, and in the end what actually gets done.
It also affects library development, and eventually leads to survivor bias: the users who are most likely to stick around are those whose profile best fits Rust’s current community and development directions, which in turn further increases the language’s momentum in that direction.
To phrase it otherwise, since arrays are a pain in Rust right now, people who care a lot about them are unlikely to stick around long enough in order to push the language in a direction that makes them more pleasant to use. Unless, of course, they have other interests that Rust caters to better. For example, speaking personally, I love lock-free algorithms and system tools, and Rust is a joy for that.
When it comes to technical direction, Rust has so far taken the Haskell approach of trying to do as much as possible in libraries using few powerful language abstractions, rather than the Ada/C# approach of bundling direct support for identified use cases into the language using many focused abstractions.
What this effectively means is that use cases like number-crunching cannot be directly improved upon, and must instead await the completion of more complex language features that will take a lot more time to get done, such as const generics. More radically, some of Rust’s broadly beneficial design choices can be directly antagonistic to “direct” number-crunching usability, interactions of borrow checking and bounds checking with array indexing being an easy example. If you’re doing something like 2D stencil computations in Rust, you’ll probably want to do it via high-level abstractions rather than talk to the language directly.
This “library-first” strategy of Rust has some justifications though. Languages which evolve through single-purpose features, like Ada and C#, tend to age badly. Related but disjoint features quickly pile up and increase the language’s spec complexity, resulting in unpredictable interactions, that make the languages hard to learn and hard to implement. This, in turn, leads the community to take a very defensive stance towards language additions, which ultimately causes stagnation since the missing features cannot be easily implemented in libraries. Ada is unfortunately already there, and I expect C# to get there when it will reach the same age.
Hopefully, Rust’s focus on library-building tools and will lead it to age better than that. If it does not become an expert-only language whose complex abstract concepts are impenetrable to all but a very small elite beforehand, that is.
To summarize, I don’t think that improving Rust’s number-crunching story is impossible. But for that dream to become true you will need to sacrifice a generation or two of early adopters like us who are ready to deal with Rust’s current warts in this department.
These early adopters will need, in turn, to move forward the development of a good library-based infrastructure for Rust numerics, and to push the development of language features which are needed to make such library development easier. With time, this process will hopefully lead the language to a point where it is more readily usable in this area, leading more users to join, and eventually to the Rust community becoming more active in this department.
However, I don’t think there is much to hope from requesting direct core language support for these use cases. Rust is not a numerics-focused language like R or Fortran. Innovation in this area will only be able to come from library additions, not language ones. Which is where the high-level discussions that you are hesitant about come into play