[nirui]

> It confuses easiness with simplicity

A lot of libs/packages in Go's stdlib also has this problem. They like to package everything in a very tight interface (very obvious example includes crypto/* and http), without exposing implementation detail to the end user.

Doing this of course has it's benefits, but if the feature provided by the stdlib slightly don't fit you needs, then you might have to write your own (potentially unsafe and/or less performant) one from zero.

Rust is great overall, but there's some oddities. For example their lib.rs / `mod` is very, very unintuitive, it felt overdesigned and unnecessarily complex (just see [their book]). I like what Go or Java did to their lib/package systems, it's much better that way.

[their book]: https://doc.rust-lang.org/stable/book/ch07-05-separating-mod...

[magicalhippo]

I've come to hate hiding internals. Put them in a namespace which makes it clear there's no API stability guarantees, but make them available if needed.

As you note it's just pain with no gain to properly hide them. Users can't readily work around bugs or extend functionality.

[nirui]

Sometimes hiding internals is reasonable, but it could cause inconvenient. Exposing everything could make it harder to do interface management etc.

It's really a system design problem rather than access control: if you separate functional modules in a reasonable way, then it can be better reused.

[magicalhippo]

Only if you use a backwards language with non-existing namespaces. I don't see how it changes anything if you have namespaces. After all, private/protected/public are just namespaces, they are just implicit rather than explicit.