undefined | Better HN

0 pointssteveklabnik5y ago0 comments

I thought this way too until I saw a bunch of people praising how easy the module system was because they felt it was very similar to Python's. I don't know Python well so I can't speak to it.

My working theory: each language does modules in a different way. People think "Oh, a module system, I know this" and then run into issues when it works differently than their language. Just a theory though, I have not been able to validate it, or to figure out an explanation that works for all people.

And yes, more generally: as Rust continues to grow, more and more people will hit more and more edge cases, and they cannot always be fixed, thanks to being backwards compatible. That's just how things are as they grow up. More and more users also brings more and more use cases. It's a feedback loop.

0 comments

4 comments · 2 top-level

kbenson5y ago· 2 in thread

Honestly, that idea makes a lot of sense to me, and personally, I find the module system pretty normal seeming for a modern language. I'm used to Perl and CPAN, and it's pretty similar to that, except for the option to use dir/mod.rs, which honestly seems like it's kinda nice for keeping a module contained nicely for those that want to do it that way.

Now I'm more interested in what the complaints about it are, and specifically what they're in comparison to. Either they're not used to using so many modules in a method such as this, or they're honestly expecting some better system for their use case that I'm unaware of, or a little of both, so my curiosity is piqued.

steveklabnikOP5y ago

It just really depends. I should have been writing these down over the years. A few common points of confusion off the top of my head:

People expecting to put "mod foo;" at the top of foo.rs, to declare that foo.rs is a module.

People expecting to put "mod foo { }" with the contents of the file inside the {}s to declare that foo.rs is a module.

People expecting that "use" declares a module, not "mod."

People expecting every file inside a directory "foo" to be the contents of the "foo" module, regardless of filename, all concatenated together.

People expecting that mod statements never need to exist because it should be inferred from the filesystem.

General confusion about the privacy rules; that "pub" may not mean that your thing is globally public.

General confusion about crates vs modules; main.rs and lib.rs being in the same directory, but declaring different crates. Not understanding how to import stuff from lib.rs into main.rs, because it feels a bit different than other modules.

People used to also struggle a lot with "use" and paths pre-Rust 2018, but that's been mostly cleaned up at this point.

skohan5y ago

So a point of comparison would be like a Swift or a Java where module/package definitions are defined implicitly, based on the location in the file system. In contrast, Rust's explicit module declarations seem cumbersome and unnecessary, especially since 90% of the time you're just typing out a structure which is identical to what already exists in the file system. So this could easily be inferred, but it's just not.

I think the same can be said for match statements on enums: in Rust you need to match against the fully qualified type name, when in other languages (including Zig) you can infer everything up to the enum case, since it's already specified by the type you are matching against.

These kinds of things just seem weirdly inconsistent, since in many cases Rust favors inference and elision to remove boilerplate, while in other cases it requires explicitness when there is no technical reason for it to be required, and other languages handle inference just fine.

blandflakes5y ago

Oof I dunno I'd categorize the Python module system as "makes no sense and I can never get it right" - I'm sure it's consistent but it doesn't feel approachable to me.

j / k navigate · click thread line to collapse