Gripes about the borrow checker I think would be cured with the following surprising fact, and interesting "problem solving" approach to the language's design:
In Rust there's at least 5 types of everything, in order of strength:
- Value / unqualified / "owned"
- Generically, T
- Optionally mutable
- Mutable Reference
- &mut T
- you can only have one of these for a given value
- Reference / Shared reference
- &T
- you can have arbitrarily many for a given value
- Raw constant pointer
- *const T
- you can have arbitrarily many, and they're not liveness checked
- Raw mutable pointer
- *mut T
- you can have arbitrarily many, and they're not liveness checked
Now I say at least because things get appreciably more complicated when you find yourself dealing with lifetimes which apply to "References", those are indeed themselves types, but ultimately represent a compiler-executed calculus regarding liveness relative to some Value.
They also can 'fan out' like a multiple-dereference pointer, but the tricky part is how the APIs for Types conform to these, for example;
Since there are 3 different types of things in a collection, then there are 3 different ways to iterate over them `iter()`, `iter_mut()`, `into_iter()` in increasing order of strength. Most of the breadth or early complexity arises from the urge to treat these as a distraction, rather than a fundamental aspect of systems code.
I feel like it's intuitive for me to think about this stuff as just a second type system rather than to think about the details of how the compiler works or how it'll function at runtime. A given value exists in a kind of superposition, and I pick the form I want it to collapse into (value, reference, mutable reference, etc) based on the tradeoffs I need at that moment. I don't know exactly why this is helpful, or if it's helpful (or even coherent) to anyone but me. It might also be damning me to some conceptual outer darkness where I'll hear the pounding of accursed drums and the wailing of hideous flutes forevermore.
Definitely with my time in the language, my head chatter takes `&` operator to literally just mean "borrow" and then you're inheriting 1x indirection operations.
The only time this gets into trouble is when you bridge the &/&mut and *const/*mut worlds. If you need the latter, try to stay within them as much as possible, if not entirely.
In Rust there's at least 5 types of everything, in order of strength:
- Value / unqualified / "owned"
- Mutable Reference - Reference / Shared reference - Raw constant pointer - Raw mutable pointer Now I say at least because things get appreciably more complicated when you find yourself dealing with lifetimes which apply to "References", those are indeed themselves types, but ultimately represent a compiler-executed calculus regarding liveness relative to some Value.They also can 'fan out' like a multiple-dereference pointer, but the tricky part is how the APIs for Types conform to these, for example;
Since there are 3 different types of things in a collection, then there are 3 different ways to iterate over them `iter()`, `iter_mut()`, `into_iter()` in increasing order of strength. Most of the breadth or early complexity arises from the urge to treat these as a distraction, rather than a fundamental aspect of systems code.
Crates / modules are a bit of a meme: https://www.reddit.com/r/rust/comments/ujry0b/media_how_to_c...
Bevy has done some work investigating build performance: https://bevyengine.org/learn/quick-start/getting-started/set...