8 ms·

Modules confuse me greatly. I was trying to have both a lib folder and a main.rs and I couldn’t figure it out in 15-30 minutes, so I gave up and just put the mo

Modules confuse me greatly. I was trying to have both a lib folder and a main.rs and I couldn’t figure it out in 15-30 minutes, so I gave up and just put the module in src as a sibling to main.rs while I got stuff done - come to think of it, I’d like to revisit that.

ibraheemdev 4y ago
The most common confusion with this is that when importing library code from your binary, you use `crate_name::...` as opposed to `crate::...`, as they are separate. You also don't have to declare the lib.rs as a module from the binary, and generally all your `mod` statements will reside in your lib.rs
- faitswulff 4y ago
  Hey, your comment made me realize I'm an idiot and I was trying to make a lib folder at the sibling level to the src folder. That plus your tip about how to organize the files and everything makes sense now. Thanks!
nkozyra 4y ago
I haven't seen this as being discouraged. Rust does more things differently than most newer languages so the learning curve is there but the documentation is fantastic if you have the time or patience. I say this as someone who has stumbled my way through to competence/expertise on some good newer languages (zig, nim, go without RTFM very much, but I can't do that with Rust. But there's also a relatively early moment when you get to a local maxima and suddenly it all starts coming together.
- lumost 4y ago
  honest question, what necessitated Rust's choice of using such a different module system? Every other modern language seems to roughly map directory to module (go/python etc), or explicitly declare a folder as a module (java). C/C++ is the outlier, effectively using file as a module. Why is Rust so different on this seemingly boring topic?
  - jolux 4y ago
    Probably the influence of the ML module system, where modules are per-file and module interfaces are in a separate file.
  - pjmlp 4y ago
    C and C++ aren't the outlier, because many projects use translation units as base_os_arch.extension. And in what regards C++, we have proper modules now, which also don't map into a specific file. Java now has a mix of packages and modules, because not all packages should be public to start with. Ada introduced a similar concept in 1983. C++ modules builds on similar ideas, with module partitions. Then we have plenty of other less mainstream languages.
  - sophacles 4y ago
    I don't think it's "so different". Lets look at rust v some other common languages: rust: top-level for a crate: lib.rs module: $modulename.rs or $modulename/mod.rs or a `mod $modulename` block in lib.rs sub_module: $parent/$sub_module.rs or $parent/$sub_module/mod.rs or a `mod $sub_module` block in $parent/mod.rs python: top-level: have the right directory or file in python path module: $module_name.py or $module_name/__init__.py sub_module: $parent/$submodule.py or $parent/$submodule/__init__.py ruby: top level: have the right file or directory in import path module: $libname.rb with `module $libname` block submodule $libname/$submodule.rb with `module $submodule` block go: top-level: somewhere in gopath have dir $module that declares `package $module` (convention, you could have a different package name) module: all files in $module_name that declare `package $module_name` module: $moddir/$submodule where module files declare `package $submodule` It's not wildy different. Whats this FUD about?
  - dannymi 4y ago
    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)
ww520 4y ago
Agree. Module is a weak design of Rust.

ibraheemdev 4y ago

The most common confusion with this is that when importing library code from your binary, you use `crate_name::...` as opposed to `crate::...`, as they are separate. You also don't have to declare the lib.rs as a module from the binary, and generally all your `mod` statements will reside in your lib.rs

faitswulff 4y ago
Hey, your comment made me realize I'm an idiot and I was trying to make a lib folder at the sibling level to the src folder. That plus your tip about how to organize the files and everything makes sense now. Thanks!

nkozyra 4y ago

I haven't seen this as being discouraged. Rust does more things differently than most newer languages so the learning curve is there but the documentation is fantastic if you have the time or patience. I say this as someone who has stumbled my way through to competence/expertise on some good newer languages (zig, nim, go without RTFM very much, but I can't do that with Rust. But there's also a relatively early moment when you get to a local maxima and suddenly it all starts coming together.

lumost 4y ago
honest question, what necessitated Rust's choice of using such a different module system? Every other modern language seems to roughly map directory to module (go/python etc), or explicitly declare a folder as a module (java). C/C++ is the outlier, effectively using file as a module. Why is Rust so different on this seemingly boring topic?
- jolux 4y ago
  Probably the influence of the ML module system, where modules are per-file and module interfaces are in a separate file.
- pjmlp 4y ago
  C and C++ aren't the outlier, because many projects use translation units as base_os_arch.extension. And in what regards C++, we have proper modules now, which also don't map into a specific file. Java now has a mix of packages and modules, because not all packages should be public to start with. Ada introduced a similar concept in 1983. C++ modules builds on similar ideas, with module partitions. Then we have plenty of other less mainstream languages.
- sophacles 4y ago
  I don't think it's "so different". Lets look at rust v some other common languages: rust: top-level for a crate: lib.rs module: $modulename.rs or $modulename/mod.rs or a `mod $modulename` block in lib.rs sub_module: $parent/$sub_module.rs or $parent/$sub_module/mod.rs or a `mod $sub_module` block in $parent/mod.rs python: top-level: have the right directory or file in python path module: $module_name.py or $module_name/__init__.py sub_module: $parent/$submodule.py or $parent/$submodule/__init__.py ruby: top level: have the right file or directory in import path module: $libname.rb with `module $libname` block submodule $libname/$submodule.rb with `module $submodule` block go: top-level: somewhere in gopath have dir $module that declares `package $module` (convention, you could have a different package name) module: all files in $module_name that declare `package $module_name` module: $moddir/$submodule where module files declare `package $submodule` It's not wildy different. Whats this FUD about?
- dannymi 4y ago
  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)

ww520 4y ago

Agree. Module is a weak design of Rust.