One important technical reason is that you need to be able to add attributes to modules, like these examples:

  // Only compile this code if the “foo” Cargo feature is enabled.
  #[cfg(feature = "foo")]
  pub mod foo;

  // Platform-specific stuff, as with std::os.
  pub mod os {
      #[cfg(windows)]
      pub mod windows;

      #[cfg(unix)]
      pub mod unix;
  }

  // You can even choose which file to load the module from.
  #[cfg_attr(windows, path = "windows/mod.rs")]
  #[cfg_attr(unix, path = "unix/mod.rs")]
  #[cfg_attr(not(any(windows, unix)), path = "null/mod.rs")]
  mod platform_impl;

So they need to at least be addressable.

Interesting. This made me realize that a possible reason why some find the modules concept confusing is that it conflates the concepts of inclusion and namespacing.

edit: corrected typo

Has the joke flown over my head, or have you conflated the words "conflate" (confuse) and "conflagrate" (burn)?

Edit: I honestly think I might have just misunderstood some play on words you're trying to make. It would be something around setting namespaces and inclusion on fire, but none of the combinations I've tried in my head work out quite right.

D'oh! Thanks for the correction; there was no pun - I just intended that it combined the two concepts :-)

It confused me for a long time because:

- Other languages like C++ and C# emphasize how much namespaces are _not_ connected to files at all

- I just ignored it and wrote everything in one big file, because the Rust compiler is just as slow either way. Even in C++ it's arguable whether splitting a file will result in faster or slower compiles, because of the outrageous behavior of #include

But once I realized every file is a module, it slowly started to make sense.

Rust modules are primarily about namespacing, which is why the book only mentions the inclusion behavior in one short section at the end of the relevant chapter. For a non-namespacing include, there’s the `include!` macro.

The `include!` is not intended to be used as a _generic_ inclusion mechanism¹:

> Using this macro is often a bad idea, because if the file is parsed as an expression, it is going to be placed in the surrounding code unhygienically. This could result in variables or functions being different from what the file expected if there are variables or functions that have the same name in the current file.

¹=https://doc.rust-lang.org/std/macro.include.html

I fail to see how you draw your conclusion from that statement. It warns about the macro’s potentially surprising behavior, but doesn’t speak to the designers’ intent at all.

`include!` is analogous to C’s `#include`: it textually pastes the file’s contentents in place of the macro, but I can’t think of another way that a textual (vs. semantic) include mechanism would work.

As someone who mostly writes Rust these days, I find it really nice that I can always (as long as I don't use wildcard imports) use intra-file search to find either the definition or the file that contains the definition.

Whenever I have to touch Go code (for reading and debugging) it's really annoying to just end up going "okay, I've got the folder, now what". Or, even more annoyingly, I've just got an interface and no clue about where to find the implementation.

Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.

An architectural side effect, at least in the case of Rust, is that when a file includes many data structures, they're going to be visible to each other.

Depending on the case, this may have practical implications or not, but architecturally speaking, it's not good form.

A practical side effect is that having a lot of data structures is going to clutter the outline view in the IDE.

Hence why you'd typically stick to ~one independent data structure per module.

You can still use re-exports (pub use) to hide it from the public API.

> Or, even more annoyingly, I've just got an interface and no clue about where to find the implementation.

That bites me often times. Does gopls help in this regard? Can any tool besides the compiler help me to answer, what methods in a particular piece of code implement what interface?

Not even the compiler knows, since interfaces are resolved at runtime. You could build a list of potential implementations, but then structural typing means that it can't know the difference between an intentional and accidental implementation.

Dont most IDEs solve this.

I do C# for my day job, if I have an interface I put cursor on it and hit a key and go to the definition, whatever file it's in. Another key will cycle the usages of the interface.

This has been solved for years. More recently we've had things like Peek as well.

But if you have to rely on an IDE, it's hard to innovate in language design.

Rust does have rust-analyzer, but it uses piles of RAM and often just doesn't work. I'll periodically try it for a few days and give up on it again. Maybe it's a bug in Kate's LSP support.

I have been using rust-analyzer with vscode (on small programs) and it has been working reliably for me.

> Dont most IDEs solve this.

Working IDEs do, but Go's PLS doesn't, and that's part of the GP's complaints:

> Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.

That is why i made the switch to Goland, even if i switched to VSCode from the Jetbrains Products before.

Sure its a bit sluggish in comparison (well only when indexing really), but finally i do not have to worry about not finding something or import-completion breaking every 2 weeks etc.

Just switch, you will stop thinking about your setup and just work instead.

Python, without wildcard imports, does the same.

Usage in Haskell is a bit more mixed, but I see a lot of 'qualified imports'.

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.

`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.

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.

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.

> 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.

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.

Files aren't modules. Modules are defined in the source code the same way as any named "item" in the language, like structs and functions.

The only difference is that content of `{}` following the definition of a module can be read from another file.

You can have a module without a file:

    mod foo {
       fn function_in_foo() {}
       mod bar {
          // this is crate::foo::bar module!
       }
    }

but if you omit {}:

    mod foo;

Rust will look for `foo.rs` to drop its content where the {} should have been. But namespacing is governed by `mod` declarations alone, not files.

That's not how I understand it.

Every file is a module, but not every module is a file.

If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?

> If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?

There’s also the `include!` macro which can read a source file without making it a module and the `#[path=...]` directive which can let you use the same source file for several modules.

If you want to, you can easily make a project comprised of many modules and using only one file (or zero files)

Creating a single module from many files is also possible. It can be done with clumsy C-style includes, or more idiomatically composed from `pub use` of items from private modules. `impl` blocks can be anywhere.

The point is, files and modules are decoupled. Files just happen to be a convenient default for modules, but they aren't semantically special in Rust. There's no syntax or privacy boundary specific to files.

) Cargo.toml with `[lib] path = "/dev/stdin"` + `echo 'fn main() {}' | cargo build` happens to work :)