In that case, I will also have to admit that I find your comment a bit frustrating too, because it sounds as if it automatically dismissed opposite opinion as immature or short-sighted.
While this may sound appealing, there still are a few questions in which the right thing to do is a firm decision. I think a core value judgment in language design is perhaps one such exception. Drawing a line in the sand (after proper consideration and design, of course) is better than endless hesitation and debate about alternatives, continuous wandering in the design space while accumulating technical debt, or settling on compromises just for the sake of compromise, which are then bad for both parties. In this regard, a solid decision is both acceptable because nobody is forced to use Rust (those who don't like its fundamental ideas can try it out then leave), as well as necessary because in the lack of a very explicit direction and goals, the language won't go anywhere.
I didn't question that, although I feel that there are many users, RFC authors, etc. who, even if aware of the problem, don't particularly care about it, because it is at tension with their personal favorite feature being added to the language.
That's assuming that accumulating features is necessary or mandatory. However, it's neither. Even you cited some examples yourself (e.g. Go) which prove the opposite.
But even monotonic growth can be handled well – the key distinction is between "monotonic" and "unbounded". Unbounded growth in a software system leads to an inevitable decline of quality. So a possible solution to this quality problem may be simply not adding many significant features, instead asymptotically approaching a supremum of complexity, possibly even restricting maintenance to fixing bugs (there are still plenty of them in the compiler, and an escalating language complexity doesn't help with it).
And what about users who started using and loving the language for what it was earlier? Especially in the light of there existing several other languages out there, with features which are not available in Rust. If one likes programming with such features more than Rust's approach, they could just use those other languages instead of Rust. In other words, there's not much point in changing a language with the goal of making it more similar to another language. It's also by itself a strange idea to suddenly shift the target audience from those who liked Rust for its original profile, toward those who would like it for its future similarities to other languages, or for a completely different paradigm that they hope would be adapted by Rust, and who are consequently pushing it in that direction.
Incidentally, I think a new paradigm could even warrant the design and implementation of a new language — but why take away the existing language from its current users who like it just the way it is (give or take a few rough edges)? We can't possibly cater everyone anyway, and I don't think that would be a healthy goal.
On a related note, someone has mentioned it a couple days ago, but I also find it very strange and backwards that the burden of proof is on those who want to keep the language on the current track, and not on those who want to change it. We consantly keep having to defend the position that Rust treats specific constructs the way it does for good reasons, which have been discussed and evaluated thoroughly, which work well in practice, and which were chosen to be different from other languages because they are a better solution than what is found in other languages. And if we get tired of this endless fight, we find ourselves in a situation whereby the language suddenly changes under our feet without good reason.
Apart from how frustrating that situation is, it also makes it impossible to build a solid foundation upon the language. If idioms and best practices change sharply and suddenly, then code written today will become technical debt tomorrow. New programmers won't understand why something was done differently in the "old days", because the book, the community, and lints will teach it exclusively the new way. Even with a technically upheld "stability guarantee", this would pretty much undermine all practical attempts at stability and long-term maintainability. Maintainability and stability of code doesn't stop at "it will keep compiling". It includes "it will stay easy to understand and modify by future generations" as well.
Radical changes to the language such as this one can't really be considered "filling out". I've said this before, but in my opinion, Rust would benefit a lot more from actual filling out, i.e. the implementation of accepted features, the refinement of existing ones, and above all, bug fixes. The act of changing the core idioms would effectively hijack the language.
Yes, that's exactly what I was trying to describe above. Proposals which try to change the core identity of the language also result in backwards-compatibility-induced bloat, although I would argue that's the smaller problem; shifting the identity in itself is the more serious one, because it basically makes the the language's existence pointless.
That is an excellent question, although I don't see how it's relevant to this discussion. Anyway, given how well current Rust is designed, it is highly unlikely that its core identity turns out to be just plain wrong within a time frame when the language, or at least its stability, still makes an impact. C is an excellent example of this phenomenon: it was the best way to do systems programming back in the day, but over time, its uncontrolled, unchecked, weakly-typed approach to accessing hardware and resources turned out to be unnecessary and too dangerous. 40-odd years after the birth of the language, we can now design better systems programming languages in the hope of replacing C, without the need of either growing C ad infinitum backwards-compatibly, or changing it and breaking people's old code. The C standards committee and community seem to have realized and embraced this; unfortunately, the C++ community doesn't, and now they have an identity problem.
That's quite a hyperbole. If you look outside the design-by-committee world, you will find plenty of counterexamples. Most functional languages' users love and admire the mathematic beauty and purity of their favorite language, usually not without a reason. Some major scripting languages, such as Python and Ruby, also have a user base agreeing that the language is good for the purposes it was designed for. Sure, there are many other languages that have a reputation of being a "pile of junk" (and rightfully so), but it's not a necessity. Why should we set our own standards so pessimistically, then? "It will turn out to be bad anyway, so we might as well not care at all (or let anyone actively mess it up)" is not constructive, because if we think about Rust like that, then what was the point in the first place?
If the Rust community manage to keep the language sane, reasonable, and faithful to its original fundamental values, then I think it can realistically have such high hopes. Otherwise, probably not.
With this claim, you are degrading anyone who is concerned about the growth in complexity of the language, to the level of someone clueless who just automatically contradicts everything with a knee-jerk reflex. Please consider that most of the so-called "don't be like C++" arguments have solid and extensive technical reasoning behind them, and highlight important technical as well as social/cultural issues.
Again, this ignores the fact that people do regularly give detailed, professional arguments as to why they consider a specific feature or change to be a bad idea. So the claim that the entire opposition can be summed up as "pointing to C++" is an oversimplification at best, a strawman at worst, and in either case is simply untrue.