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