Please don't take this the wrong way, it's just the editor in me.

There's a typo at the end of the Error Handling section:

When you need to explicitly handle an error, you omit the question mark operator and use thw Result value directly.

> Personally I didn’t have borrow checker problems, but that’s because before I started using Rust at work I’d designed and built my own borrow checker. I don’t know if that’s a scalable pedagogy.

Yeah... maybe not, but I can see this being a project in an undergraduate course.

My biggest issue with rust after two years is just as you highlight: the mod/crate divide is bad!

I want it to be easier to have more crates. The overhead of converting a module tree into a new crate is high. Modules get to have hierarchy, but crates end up being flat. Some of this is a direct result of the flat crate namespace.

A lot of the toil ends up coming from the need to muck with toml files and the fact that rust-analyzer can’t do it for me. I want to have refactoring tools to turn module trees into crates easily.

I feel like when I want to do that, I have to play this game of copying files then playing whack-a-mole until I get all the dependencies right. I wish dependencies were expressed in the code files themselves a la go. I think go did a really nice job with the packaging and dependency structure. It’s what I miss most.

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

  - 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.

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...

> with cargo you praise the absences: there’s no gotchas, no footguns, no lore you have to learn in anger, no weirdness, no environment variables

Suppose the author doesn't use build.rs, which appears to have been composed of the listed things almost entirely.