← Back to context

Comment by the__alchemist

3 months ago

Great write-up. I do the array indexing, and get runtime errors by misindexing these more often than I'd like to admit!

I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

7 comments

the__alchemist

Reply
serbuvlad  3 months ago

I've always thought about this. In my mind there are two ways a language can guarantee memory safety:

* Simply check all array accesses and pointer de references and panic if we are out of bounds and panic/throw an exception/etc. if we are doing something wrong.

* Guarantee at compile-time that we are always accessing valid memory, to prevent even those panics.

Rust makes a lot of effort to reach the second goal, but, since it gives you integers and arrays, it makes the problem fundamentally insoluble.

The memory it wants so hard to regulate access to is just an array, and a pointer is just an index.

  • meheleventyone  3 months ago

    Rust has plenty of constructs that do runtime checks in part to get around the fact that not everything can be expressed in a manner that the borrow checker can understand at compile time. IMO Rust should treat the array/index case in the same manner as these and provide a standard interface that prevents "use after free" and so on.

Animats  3 months ago

> I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

Yes.

Three months ago, when the Rust graphics stack achieved sync, I wrote a congratulatory note.[1]

    Everybody is in sync!

        wgpu 24
        egui 0.31
        winit 0.30

    all play well together using the crates.io versions. No patch overrides! Thanks, everybody.

Wgpu 25 is now out, but the others are not in sync yet. Maybe this summer.

[1] https://www.reddit.com/r/rust_gamedev/comments/1iiu3mr/every...