Java does not have folders as modules. See also https://www.oracle.com/corporate/features/understanding-java-9-modules.html https://www.oracle.com/corporate/fea

Java does not have folders as modules. See also https://www.oracle.com/corporate/features/understanding-java-9-modules.html https://www.oracle.com/corporate/features/understanding-java... for the actual modules. Packages (namespaces) are not modules. For a programming language to get modules right (so that they actually give you modularity in big projects) is very difficult. I had a website with a two-character domain name that talked about good module systems, but I can't remember it. Anyway, there they said basically that with libraries, what you want is your library to be able to split up into several abstract modules, whose names and exports are part of the API (!). Inside each module, you have functions, data structures etc. So you'd have library libtcp having modules "auth", "transport" and "data_link" or whatever. Those in turn depend on symbols from other modules in this library or another library. The point is there's always the extra module layer in-between. A lot of languages don't have this extra layer, and not having it is a grave mistake for big projects. C has no modules or namespaces. That's obviously bad. C++ has namespaces (kinda what Java calls "packages"), but no modules in the meaning above, and no formal libraries. That makes the whole thing a mess with global state of other libraries intermingling with your library etc. I've had a long-time embedded C++ programmer friend stop programming C++ entirely because he just couldn't take it anymore how unrelated crap you don't care about fucks up your own library just because you #included something and that #included something you don't care about. Obviously, don't design a programming language like that. (they are trying to introduce proper modules into C++ now, but imo it's too late) So the summary why Rust does it how it does: Because to do it this way it makes good programs. Rust's "mod" statement defines a module. Naturally, that means that by default you have nothing from before in that module. It does NOT automatically import (or for that matter, export) things (that would destroy modularity), but if you want to you can do "use super::foo" to get some function from the parent module if you absolutely have to, or "use libx::auth" to get some module from some other external library, or "use crate::auth" to get some other module from your own crate (crate means library or program). If you can have one module nesting, it's nice to also have multiple module nestings, a module defined inside a module. You need to have a root module. And that's either lib.rs or main.rs, depending on whether you mean the library or the main program. Other than that, the "mod" statement is pretty similar to how Python does it: if you say "mod x", it will try to find x.rs, and if that's not there x/mod.rs. Python would be: "import x", it will try to find x.py, and if that's not there x/__init__.py. The Rust extension is that you can also write mod x { ... contents here } and that's a neat gimmick. To say that a module system is mundane (like the article says) ignores that a lot of progress in system design scalability in the past >30 years came from improvements in modularity. It is anything but mundane in big programs. There are entire programming languages that are named after their module capability (for example Modula)