The rust-lang.org page says: Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.
That is basically: safety, performance, concurrency; pick three.
That’s the number one goal of rust, though at this point, it’s just splitting hairs. The #1 focus of Rust development in 2017 may be improving the learning curve, but that goal isn’t at the expense of everything else. If you want a language that’s easy to learn and sacrifices any of the three things above, I’d recommend Lua.
At a high level:
I don’t personally think the Rust learning curve is that bad and the places I think it happens to be bad is in the places where people made changes to the language to make the learning curve better, like autoderef, as an example.
Even if I did buy into the idea that the learning curve is bad, I wouldn’t focus on changes to the language or the module system. That would primarily result in instability and confusion. I’d focus on documentation and other educational initiatives. And where I did make language changes in this vain, I’d have to prove to myself that making the change will improve the experience for the vast majority of Rust users, at all skill levels.
Even if I did believe that changing the language was appropriate and modules was a big problem, I don’t see how either of these changes makes it easier for Rust users at all skill levels to learn Rust in the long term.
You can write
mod foo; in a non-root crate, it just refers to
src/**/foo/mod.rs or equivalent instead of
src/foo.rs or equivalent. You can write
use <identifier>; in the root crate at all, because any individual identifier you can put there is already imported. But that issue is one of name lookup and has nothing to do with
mod doesn’t do name lookup, it introduces a name.
Rust has 2 core concepts and 1 auxiliary concept:
- Declaring names in the current scope:
enum foo, etc.
- Using names from the current scope:
- Using names from the current scope and declaring them as different names in the current scope:
extern crate foo as bar
As far as I can tell,
use statements are for convenience. Perhaps they are required in corner cases, but if you’re willing to type the entire name every time, you don’t need them. Reexporting names using
pub use isn’t a beginner feature anyways.
If someone doesn’t understand the distinction between the three scenarios above, then it doesn’t matter what the syntax is, they’ll have issues with Rust. And hiding
mod from them isn’t likely to help or even delay the learning curve in a useful way.
And as for other languages:
module.exports to declare a module. Python seems to require a
__init__.py file in a directory and Java requires
package statements. They are all different ways if indicating that the module system is in use and they are different from the way Rust does the same. I don’t see how they impact this discussion at all, other than to suggest that there are huge inconsistencies and misconceptions between languages and their module systems.
As for whether a novice needs to know
mod, it depends on when you want to teach them code organization. When would someone in JS learn about
modules.exports? Or a Python programmer learn about
package in Java? None of those things are part of tutorials because code organizations isn’t usually part of a language tutorial. I don’t need
mod in Rust to write a single file program as part of a tutorial, so why is it part of the critical path?