I am convinced; flat is the way to go.
But this leaves us with an unfortunate bit of inconsistency. To resolve that, I feel Rust should eliminate namespacing in all its unnecessary forms. After all, if programmers are forced to keep all their code in a single, flat directory and namespace, it will encourage more meaningful and memorable names for items and source files!
Obviously, names would need to be globally unique across all linked crates, including ones you’ve never seen before locked away in private repositories, but again, that just encourages good naming!
And if people really feel compelled to use namespacing, they can always prefix their structs and functions with some unique word. After all, if it was good enough for C, Objective-C, and FORTRAN, I fail to see why it won’t work today!
Remember, those languages were surely designed by experts, and I’m sure they knew what they were doing!
I don’t buy “appeal to tradition” arguments; such are the death of innovation and progress [1]. Nor do I buy the “you can fake them” argument, not when namespaces have become a must-have feature in any language designed in the last twenty odd years. You can fake string literals with arrays of integers, but any language trying that would be laughed out of the room.
Yes, yes, I know the two are not exactly the same thing. Fairly different things, really. But I still feel that the reasons for having namespaces, logical and organisational grouping, are as relevant to a package index as they are to filesystems and source code.
Does it really add that much complexity to (at least for the moment) just require all package names to be of the form “owner/name
” with a special exception for “official” packages? Sure, I’d love arbitrary hierarchies (grabbag
and grabbag/macros
makes the relationship much clearer than grabbag
and grabbag_macros
), but just namespacing by a completely arbitrary, unchecked prefix would do a world of good.
+1 for namespaces, even if it’s just one layer deep with usernames or some other arbitrary prefix.
[1] Though, obviously, that doesn’t mean history should be ignored; merely that the reasons behind old decisions should be re-evaluated rather than taken at face value. Maybe C lacked namespaces because code bases were smaller, there was less of a “library all the things!” culture, and there were serious technical limitations that forced “simple over elegant” design. Just sayin’