2D arrays, lack of

This comes up every few years. I'm just asking if there's been progress.

I am looking for simple 2D vectors. Matrices, really. Something where I can write

  use glam::{Vec3};
  const COLS: usize = 100;
  const ROWS: usize = 200;
  let mut mat1: Matrix<Vec3> = Matrix::new(ROWS, COLS);
  for i in mat1.rows() {
      for j in mat1.cols() {

There's ndarray, but it's complicated and not stable yet. The developers write "Still iterating on and evolving the crate. ... breaking changes are expected during evolution from version to version". They went down the "more cool features" rabbit hole. That's a general problem with array libraries. Some people want choice of axis, row and column swapping, and rectangular subarrays, all of which complicate the underlying representation. Then you get a huge, brittle package. Is there something simple and stable?

Vec of Vec is no solution. All those allocations for each matrix, plus lousy cache layout.

Someone must have written this as a simple generic.

1 Like

You might be interested in Grid.


That's about right.

That would be a good candidate for "std". It's needed often, and it's better if there's only one of them.

1 Like

I disagree. I don't think it needs to be in std at all. I would rather not lock in the API as stable and then be stuck when a new "better" way comes along later.


Maybe I am misunderstanding the question. Is all what you are looking for:

idx(y: usize, x: usize) -> usize { y * row + x }


The problem is that the issue of 2D arrays is not simple. If you look into the history of programming languages, then you'd see that there is no consensus among the way to represent and access 2D arrays. The manner depends heavily on your application and somewhat on taste.
If you want a taste of how weird this gets, I'd suggest you read Chapter 9 of the "Expert C Programming" book by Linden.
I'd say with the ever changing processor design, 2D arrays will always be a bone of contention. And thus never end up in the standard library.


Setting aside advanced features like sparse representations and sliced views, there’s no consensus even on the fundamentals. Both row-major and column-major storage orders are in wide use, for example: Do you pick one, or try to write a library that can handle both?


You can't tell which way the array is represented.

I'd just like to reach the level of support in FORTRAN and Matlab. The key idea is to have one representation used by most libraries, so you can move matrix data around easily. It's probably too late for Rust. though.

I am not familiar with 2D vectors at all and what the advantage would be. Though I do feel like I have a similar situation where I might need them, since other people use it in that context.

This is a huge talk, but there is Rust being used: link and I do see stuff like Vector2 being used. Not sure what she uses, however.

If this is not what it is what I think it is. Could you enlighten me why a 2D vector would be an advantage? Cause as I said I am trying to recreate something similar to the link.

The layout of a 2D array doesn't usually affect the API much, but it certainly affects which algorithms you can use with the array without performance issues. Applications of 2D arrays often need to care about performance to some extent, so the choice does matter.

I watched that talk closer to when it came out, and I haven’t rewatched it to confirm, but I am fairly certain that the speaker is talking about a struct repressing a 2D vector, that is, two numbers representing a displacement in two dimensions.

Probably something like this:

struct Vector2 {
    x: f32,
    y: f32,

Despite the confusingly similar name, that’s not the same things as a 2D array, which this thread is nominally about.

Arguably it would have been less confusing if Rust had not copied the name Vec from c++’s std::vector.

1 Like

If you case of use is relative small matrices and vectors(my case of use is Robotics and simulations) i do a crate for that:


the API is very simple, is the only one that don't use unsafe code for gain performance and the performance is very reasonable you can view the bechmarks here:

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.