What's the rationale for making files modules? Modules being namespaces, and namespaces being collections, it's not desirable to have a file being a (large) collection of code.

The feature that gives mixed feelings to the author (Re-exporting Imports) is indeed a workaround to this; since each file would externally generate one extra namespacing level, one reexports data structures in order to remove that level.

This is odd, as it's essentially boilerplate by design. Am I missing something?

I agree the modules are annoying. I realize that the "standard" Rust style is import everything you need. However personally I have long worked with code that avoided imports and found it very helpful to read as it was obvious where each type of function was coming from. However the deeply nested imports makes that painful in a lot of Rust libraries.

For example `std::time::Duration`, `std::path::Path`, std::cmp::Ordering`. I wish everything was just directly in `std` such as `std::Duration`, `std::Path` and `std::Ordering`.

This re-export that the article talks about is doing this change (which I think is great!) while keeping a nice file structure. I think it is a shame that Rust conflates how you organize your code and how the user of your library sees it by default. However this seems like the best compromise.

Example of this pattern in my code: https://gitlab.com/kevincox/mario-solver/-/blob/137ac5dea067... (however since this isn't a library I use `pub(crate)` instead of `pub`. It works just fine with `pub` except you get a warning if the file doesn't have any exports which is a little annoying).

Every time this post series comes up I have to remember that it's mostly a summary of TRPL.

“Prelude” is borrowed from Haskell, right?

As a sidenote, does anyone else find the language identification terms cringey? Rustacean, gopher, pythonista... just atrocious.