[curun1r]

> ...because more modern languages are doing this out of the gates and with far fewer hacks and more out-of-the-box tooling (e.g. Rust)

Haha...I love Rust, but you must not have been following the recent saga over modules in the community. Two things became abundantly clear:

1) There are definite issues with the current way that Rust does modules and they create problems for newcomers that don't know all the intricacies.

2) There's very little consensus in the community about the best way to fix those problems.

Initially, a couple of different, somewhat major proposals were made that would largely overhaul the system. Over the course of a few iterations, those were whittled down to a few, much smaller changes that mostly keep the current system but remove some of the stumbling blocks. It's a credit to the Rust team that they've handled it in such an open manner, but it's also creating a bit of a "design by committee" feel that's probably going to create something that everyone can live with and very few will think is close to perfect.

[Rusky]

The problems the Rust module system has and the changes being made to it are purely syntactic. Rust has already solved, and isn't changing its solution to, the kinds of problems Java is solving with Jigsaw.

FWIW, I don't agree with the "design by committee" assessment on the new system, either. There was certainly a lot of committee-flavored input, but it was only used for brainstorming and gathering requirements. The actual RFC, especially at this point, is pretty coherent and put together by only one or two people.

[kibwen]

> it's also creating a bit of a "design by committee" feel that's probably going to create something that everyone can live with and very few will think is close to perfect.

I wish that the term "design by committee" didn't have the stopping power it has. Rust's current module system absolutely wasn't designed by committee, and if there's one complaint that I'd levy against it it'd be "overengineered", which is typically what people seem to tend to expect from systems designed by committees!

Personally, whether or not something is designed by a committee is orthogonal. What matters more is whether that something is well-integrated with the sibling systems that it is integrated with (read: unsurprising), and whether its design exhibits good taste (obviously, openly, wantonly subjective, but perhaps we can usefully say that a design can be judged to have good taste if it is so judged by people who think that its sibling systems also have good taste (so read: consistent)).

In truth, there probably is a positive correlation between things that are designed by committee and things that violate the two principles above; it's hard to get lots of people to commit to a consistent vision, especially if that involves serious tradeoffs. It's part of why languages with BDFLs tend to be considered at least coherent, if not elegant: it's easy for a committee of one to have a vision consistent with itself. But where this pejorative doesn't necessarily apply is when the committee is small, close-knit, and all share the same values.

When it comes to Rust, the committee in question is the language team, which is just seven people (in contrast to the dozens of commenters on this issue, who are there to provide perspective and arguments, not to cast votes). Of these, the team lead (Niko Matsakis) is someone that I personally trust to have excellent taste; I feel the same about the RFC author, Aaron Turon, who is also on the language team. And, for better or worse, teams choose their own new members, which gives good taste the chance to propagate; this runs the risk of stagnation (lessened, hopefully, by the RFC process), but also avoids the fractured nature of committees assembled from far afield.

For the record, the module system is exactly one of those things that I've long felt is subpar about Rust (though still better than headers, obviously--that's not a debate, it's a massacre). I haven't had the chance to play with the revised modules RFC yet, but we'll have a lot of experience with it before it potentially gets stabilized, and from what I've read it does look like it ultimately improves consistency and reduces surprises when judged against the rest of the language, which makes me optimistic. I'd love to have to find something new about Rust to whine about. :)

[curun1r]

For the record, I wasn't talking about the overall module system with my "design by committee" description, just the recent proposed changes. Whether there were only 7 votes or not, it definitely felt like there was an effort to appease as many of the people who commented on the issues as possible, and that wasn't a small number. Don't get me wrong...I think the community that has developed around Rust is awesome and somewhat unique for a technical project when it comes to the respect and civility that gets exhibited. But I think the module system is an area where having a talismanic figure capable of hearing input, deciding on a design aesthetic and then pushing the entire community to buy into it would yield superior results to a make-everyone-happy approach. And it feels like the changes that will be coming to Rust are more of the latter and limited to just the things that almost everyone agreed upon.

The difficulty is that I think the Rust process works better for changes that aren't as disruptive or fundamental to the language. The RFC process is not only open and fairly welcoming to people outside the core team, it's also a great educational resource. I've learned a lot about language design from reading the RFCs and the accompanying comments. So I don't think I'd trade the Rust model for a BDFL model. I just wish something more like Aaron's original proposal (the second original proposal, that is...the one that got turned into the most recent one) was being implemented, even though I disagreed with a good chunk of it.

[TeMPOraL]

Yeah, design by committee isn't a bad thing. See e.g. Common Lisp which, being defined by an ANSI standard, shows how great things can be when you have a committee made of smart people who inform their work by carefully evaluating what other smart people before them tested in the field.

[patrec]

    (setf (readtable-case *readtable*) :invert)

[TeMPOraL]

Yes. What about it?

It's a useful feature to have, as it makes Lisp reader more flexible. See the summary of the discussion by the committee here: http://clhs.lisp.se/Issues/iss286_w.htm.