> Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging. To be cl

> Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging. To be clear, safe Rust doesn't actually have pointers. (Well, it does, but only unsafe Rust can dereference them.) But Rust does have pass by value and pass by reference. It has both stack allocation and heap allocation. And it has a notion of who "owns" something. These aren't technically pointers, but taken together, they're basically a safe interface to doing "pointer stuff." Conceptually, all these ideas should make sense to anyone who has worked with pointers and allocation. Similarly, Rust allows easy mutable state as long as only one piece of code can see the mutation happen. But many programmers are used to being able to share mutable state between widely separated bits of code. And this affects how you design the architecture of your program! Anyone who has done functional programming will see the implications of this early: "Oh, I need build my architecture around immutable state!" So something like an old-school game engine where any entity can update any other entity is a huge headache in Rust. But a game architecture like ECS that carefully restricts mutation (like Bevy) works beautifully with in Rust. I don't want to trivialize this: Pointer stuff and mostly-functional architectures are both real skills that take time to learn. Rust is amazing for situations where you feel torn between TypeScript and C/C++. But lots of projects just need a nice GCed language and a good standard library, and Rust wouldn't be the right choice for many teams.