Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This was my experience, too. I had to keep checking other crates to see what was expected from me, and managed to finally understand through trial-and-error.

The problem with this is that I'm not likely to remember how modules work a few months after finishing a Rust project. I reckon core aspects of a language should be so simple that they don't need any work memorising them.




Mine too, or rather, for my first rust project I initially had all the code in main.rs and then I found it very difficult to split up the project into several source files. I think with some better documentation it wouldn't have been that hard.


I think it's the documentation. It took me a few tries to get everything I needed out of the Book to use my own modules, but then it was easy.

Although I still don't quite get how macro importing works. It feels like when you #[macro_use] on an extern crate you get all the macros implicitly everywhere without having to issue any use statements. This seems weird and I have yet to try to find an explanation of it. But I've got modules all over my Advent of Code solutions which use macros from nom without having any nom-related use statements.


Yeah, I hear you. I've always thought this, and honestly, I think the issue is that I've always found the module system _very_ intuitive, so it's been harder for me to connect with how people struggle to learn it.

http://rust-lang.github.io/book/ch07-00-modules.html is the second edition of the book's chapter on it, I think it's much better.

> This seems weird

Yes, that is how it works. Macros aren't in a namespace. Yes, it's weird. It's an artifact of history; eventually, it will be fixed.


> http://rust-lang.github.io/book/ch07-00-modules.html is the second edition of the book's chapter on it, I think it's much better.

It is better, yes, although I think it takes a while getting to the point in a few places.

Docs are something I'm interested in, so you might hear more from me through appropriate channels about this and that.

> Yes, that is how it works. Macros aren't in a namespace. Yes, it's weird. It's an artifact of history; eventually, it will be fixed.

I'm glad that I both got it right and that it's not necessarily going to stay that way. I don't know how much macros are going to proliferate in the future, but I don't want to find myself with macro naming collisions. I can certainly imagine some of nom's causing issues with other crates, and having to define a new crate within my tree just to contain them would be irritating. I assume that would work as a workaround, anyway.


Great. Please don't hesitate to reach out and or file issues or whatever, I really want to make this stuff good.

Basically, today you define macros with macro_rules!. This shipped in Rust 1.0 because we did not have the ability to invent and implement a more proper macro system, and didn't want to hold the whole language up on one thing. In the future, you'll write macros with a "macro" keyword, and macro_rules! will be deprecated, and "macro" macros will support namespacing, etc.


Is that "Macros 2.0", or something beyond that?


So here are some things the book chapter misses that are source of confusion elsewhere in this thread

- `extern crate` is logically a crate-internal magic `pub mod` or `pub use`

- You should usually put your `extern crate`s in the crate root

- Putting these two together, you can refer to crates as if they were toplevel modules.

This is one of the very common confusions I've seen.


Mind opening an issue with this in it? <3





Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: