[gameswithgo]

while it would be nice to have a simple, C like language, with memory safety, but without GC, it may not be possible. Some of the complexity of Rust is to help deal with life of borrow checker land.

There are some middle ground options though, like Zig, which is a nice simple C like language with less undefined behavior and no nulls. so safer, but not offering memory safety.

[Rusky]

There is a lot of unexplored wiggle room in the design of borrow checking that might get closer to what you want.

For example, Rust puts &T and &mut T at the forefront, which leads to a slightly alien way of handling aliasing- it's all or nothing. This makes some things feel way harder than they are in C, but helps out the optimizer (every pointer is now restrict/noalias).

A different language could emphasize (the equivalent of) &Cell<T>, which allows shared mutability but restricts certain "shape changing" mutations. Most of those C patterns would feel easy again, with a bit less of Rust's non-safety-essential guarantees.

[0815test]

Cell<T> (1) is not safe to reference across threads, and (2) can only mutate via the equivalent of a memcpy. It can be useful in many ways, but there is a real sense in which &T and &mut T (which would probably be called &uniq T, if Rust devs cared about theoretical cleanness over reusing short keywords!) are truly fundamental.

[Rusky]

Point 2 is only a limitation of the current standard library, not of the language-level model. It has even been relaxed recently, so you can go from a &Cell<[T]> to a &[Cell<T>]: https://github.com/rust-lang/rust/pull/61620

The same could be done for struct fields if the type system knew about it, and the whole thing could just use normal syntax.

Sharing between threads still needs &T or &mut T (or an owned value), but that's not usually involved in the painful cases.