IMO the problem is not private-by-default but small modules and the confusion of scope with packages. (I should say that my Rust experience is non-existent so correct me if my intuition on its semantics is wrong).
It's reasonable that individual Rust files have their own scope. But it is a nonsense to imbue a namespace with an API or versioning story. Programmers do not think that way.
What has an API? A package. Something big enough that you can submit it to a package manager.
Therefore, private symbols in a package should be public to that package. That doesn't mean they should be in scope, but they should be available to be imported by other files in the package.
Public/private would then only be relevant at the boundary between packages.
There's a good reason to do this: it encourages modular design. A small-module language like Python uses modules so much that they miss the opportunity to take on a life of its own.
For instance, Django is split into hundreds of tiny "modules". But no one of them is big enough to be meaningful without the others. There is no singular "Django templates" module, nor a "Django ORM" module. In that sense it is monolithic via over-modularization.
That's a very interesting point of view, but it doesn't quite mesh with my view of the world. I think it makes perfect sense for modules much smaller than "packages big enough to be submitted to a package manager" to have small, well-defined APIs. I'm not sure why thoughtfully limiting APIs would be a good thing at the package level but a bad thing at the module level.
Seems like there's a good case to be made for a 3rd level of visibility between private and public. Similar to Java's package level. I'd like to see (from least to most public):
private: only visible inside the current namespace/module
crate (possible name): importable anywhere in the current crate/compilation unit
public: visible outside the crate/compilation unit
It's reasonable that individual Rust files have their own scope. But it is a nonsense to imbue a namespace with an API or versioning story. Programmers do not think that way.
What has an API? A package. Something big enough that you can submit it to a package manager.
Therefore, private symbols in a package should be public to that package. That doesn't mean they should be in scope, but they should be available to be imported by other files in the package.
Public/private would then only be relevant at the boundary between packages.
There's a good reason to do this: it encourages modular design. A small-module language like Python uses modules so much that they miss the opportunity to take on a life of its own.
For instance, Django is split into hundreds of tiny "modules". But no one of them is big enough to be meaningful without the others. There is no singular "Django templates" module, nor a "Django ORM" module. In that sense it is monolithic via over-modularization.