I’ve only dabbled in Rust, I’ve read about Zig with earnest interest but no bandwidth to even dabble. My primary experience is with higher level languages. It’s

I’ve only dabbled in Rust, I’ve read about Zig with earnest interest but no bandwidth to even dabble. My primary experience is with higher level languages. It’s quite possible my intuition here is very wrong, but I’m sharing it because my experience with Rust’s lifetimes felt so awkwardly unnecessary to me. Lifetimes for memory make sense if you might modify memory. What if you don’t? My sense of a “smaller Rust” from my time exploring it was “why does everything assume it has a longer lifetime if I’m never going to access it again, if I’m never going to grant access to any other function, as soon as my function exits?” I’m coming from a functional programming perspective, which I thought I’d found when I started with Rust. But it seemed to want to guard me from things I wasn’t even trying to do, in anticipation that in some unrelated part of the codebase I’d suddenly abandon all of the values I’d been respecting and start interrogating into their bits. What if the “smaller Rust” is just “Rust with lexically scoped lifetimes unless you say otherwise”? I can imagine a borrow checker that defaults to the generally FP semantics of Rust’s syntax, rather than defaulting to the generally DSL-over-machine-code that’s typical of low level languages. I’m not sure what the language and implementation trade offs would be, but my instinct with Rust is that it would be simpler for most use cases, and not much more complex for the cases closest to C.