Hacker News new | ask | show | jobs
by q3k 2046 days ago
Yeah, Rust's module system is also something I find very difficult to work with after working with Go. Any time you end up with a lot of code/logic/types in a single module you have to either deal with a multi-kloc file, or try to shoehorn it into further namespacing, even if it doesn't make sense. Both options are annoying to both read and write, and

I wish I could just split up complex modules into multiple files without the extra namespacing.
1 comments
eptcyka 2046 days ago
`mod shard; use shard::*;` doesn't seem too bad IMO. Unlike Go, the compiler won't just parse all files in the source directory, but rather it'll build a tree of modules from the entry point and parse those.
link
q3k 2046 days ago
Yes, but then you introduce new scope. If shard1::Foo depends on shard2::Foo, you then end up with a murder of import statements at the top of every file. Not to mention, splitting along the lines of inter-dependency does not necessarily correlate with splitting by readability/relevancy.
link
eptcyka 2046 days ago
Yes, but this downside is not unique to Rust. It certainly exists in Java, Typescript, Kotlin and others. I'd much rather be certain where an imported type is coming from rather than having to search through all of the files. Of course, this is what an IDE should do, but even still, it saves the IDE's time. I fear long files less than the go module system.
link
littlestymaar 2046 days ago
> Yes, but then you introduce new scope. If shard1::Foo depends on shard2::Foo, you then end up with a murder of import statements at the top of every file.

Wait, what? Import statements are recursive in Rust, if shard1::Foo depends on shard2::Foo, you just need to manually import shard1::Foo.

link
q3k 2046 days ago
Of course. I mean importing shard2 within shard1. You can always `use super::*` but, ugh.

And with most imports in Rust being unqualified (that seems to be the idiomatic approach), I then find it difficult to differentiate types that are from a sibling, internal module from types that are important from external crates. Especially at site of use of the type.

Go's “local package names unqualified, everything else qualified” makes it much easier for me to read code without first having to parse all the import statements.

link