I have to admit I found this comment a bit frustrating, because the idea that infinitely accruing new features has ultimately negative consequences is not exactly a revelation - we’re all very aware of it. The argumentum ad C++ has been made many times before. I’d love it if we could, as a community, move past this framing (just as wish we’d move past “explicit is better than implicit”), into a more nuanced analysis at how languages grow over time and how we can prevent a situation in which the language becomes dauntingly massive. All of us are concerned about this, can we shift the conversation to one which produces new insights?
Here are a few notes of my own toward that end (in no particular order, making no unified argument):
- Languages change primarily in response to user needs. Backward compatibility means that language change is necessarily monotonic growth.
- Different users have different - often conflicting - needs based on their different relationships to the language. We must balance these users needs against one another, and be empathetic to users with different needs from our own.
- Rust at 1.0 was necessarily the smallest version of Rust that will ever exist from now on.
- The few languages that have grown almost none at all since being released did so by narrowly limiting who they are for (I’m thinking of Clojure as the best example of this; Go to some extent, but I see them as only halfway into this philosophy). The use cases that Rust is targeting are too broad to simply discount most users like this.
- The 1.0 release established the core identity of Rust (i.e. ownership, borrowing, traits). But it was understood at the time that it was a skeleton of the language Rust planned to be. Rust has been proved out, it is now in the process of being filled out.
- The current phase of Rust development (“filling out”) will someday end, and a new phase will begin. The big question is when have we “filled out,” and what will come next?
- More than simply accruing features, the real challenge languages like C++ face is trying to shift their core identity without breaking changes (i.e. from “C with classes” to “safe C++11” and beyond). This seems to be the cause of much of C++'s negative reputation - you’re not supposed to use half of it.
- If an aspect of Rust’s core identity comes to be seen as wrong, what do we do? Do we make a major breaking change (Python)? Do we backwards compatibly shift our identity (C++)? Do we just accept it and maybe start working on new languages (who has done this? perhaps C?)?
- Billions of lines of code and a reputation as a pile of junk is the best outcome any language has ever had, if we’re optimizing for impact on society or the industry. Can Rust really hope to have a better outcome in 2050 than C++ has in 2020? Should we really feel disappointed if it doesn’t?
These aren’t meant as challenges to you in particular, and I’d ask you not to respond to them as such. These are open ended statements and questions to try to dig us deeper into this question and past the reductive “don’t be like C++” narrative that I see the conversation currently ending at.