I am teaching a Rust Course at the moment, and we’ve just conducted a mid-course survey, which included “what is the most difficult topic” question. The lecture about modules is the unfortunate leader:
Which of the topics are unclear? Week 4, Modules — 4/7 [57%] Week 1, Intorduction — 0/7 [0%] Week 2: Lifetimes, ADT — 0/7 [0%] Week 3: Traits — 0/7 [0%] Week 5, Functions and Iterators — 0/7 [0%] Week 6, Error management — 0/7 [0%]
There’s also at least one student who spend hours trying to split code into two files, before asking a question
Note that I explicitly covered only 2018 flavor of modules: no
extern crate, no
This is a small amount of data, of course (there’s about 50 students on the course, about 30 took the survey, and 7 answered this particular question), but it seems trustworthy to me.
The immediate conclusion is that modules are still hard to learn
However, the thing that worries me is that module system changes produced the most churn when transitioning to 2018, and the changes didn’t seem to make the situation drastically better (here I can be proven wrong by providing more data). See also this reddit thread that shows another aspect of this “change, but not for the better”: https://www.reddit.com/r/rust/comments/b65ecn/modrs_in_rust_2018_yes_or_no/.
I wonder if we could design language-design process better to avoid similar situations?
This is an extremely sensitive topic, but I personally feel that the current language-design process is relatively biased towards changing the language, rather than towards rejecting the features and keeping the language stable (we do reject more RFCs than we accept RFC, “unbiased” in his case is not 50/50). So I see this particular data point as a weak conformation of my feelings.