[easytiger]

Rust mods have to stop listening to the elite language intelligentsia.

Successful eco systems are pragmatic and idiomatically straightforward.

Everything & the kitchen sink in a language is not a recipe for success.

Every language that has a long lifespan spent a long time in feature minimal stasis too. The world won't learn a moving target.

[rcxdude]

Rust is not particularly adventerous as far as PL theory is concerned: all of the ideas in it are actually quite old (just newer than the ideas in established languages, like C). It's fundamentally quite pragmatic and you see that in most of the decisions it makes. I also don't agree that minimal features is necessary for success (even though it may be a desireable attribute of a language). Many extremely successful languages have piled on features over time, some in a far less reasoned way than rust (C actually a big outlier in how slowly it has evolved: C++, Java, C#, python, perl, PHP, etc are all large languages, with complexity in terms of number of features similar to Rust).

[carlmr]

Rust is barely a moving target since 1.0. If you only read the version releases it might seem so, but for the pragmatic programmer not much is changing. Many of the changes concern very special features that only a few libraries make use of. As a library user you don't need to learn them.

I learned Rust a few years ago and without keeping up with the latest changes too much I still feel confident I can work on current code.

[bennofs]

Having these "very special features" means that there are some things with are added to the language but rarely used. That means that you might come across code in a library that you don't understand, especially if you're not using those features in your own code.

So, I think the argument that "very special features" shouldn't be counted toward language complexity/growth is wrong, IMO. I would even say that there needs to be even more focus on those features, since they tend to be not widely known, not familar, and often there is less documentation about them, so the likelyhood that they make code hard to understand is even higher.

This is not to say that those features are unnecessary. I just don't think the justification "they are not what a pragmatic programmer will see" is good.

[estebank]

If you look at the changes and cathegorize them they all fall in one if three camps:

- sugar for quality of life improvements that benefits everyone (like ? or NLL)

- new feature that lets you do something that couldn't be done before (like impl Trait or global allocators)

- new feature that removes a special case of the semantics that can be extrapolated from already present features (like associated consts and subslice patterns)

[FreeFull]

I'd say having special features is ok, as long as these criteria are met:

1) It's obvious the feature is being used.

2) The feature is easy to look up without knowing what it's called, just based on how it's been used.

3) It's easy to understand what the feature actually does, with the appropriate context.

[estebank]

The ? operator doesn't fulfill at least two of the three points, yet it's way more loved than hated. As a general guideline I agree with your points, but it is not to be taken as rigid gospel either.

[ReactiveJelly]

The ecosystem _is_ one of my favorite parts of Rust.

Building C++ (or C) projects is such a clusterfuck that it's given rise to header-only libraries.

In Rust, everything is "cargo build", and adding a dependency is one line. This has only failed for me when there's a dependency on a C system library that I can't satisfy.

Is it bad to have too many dependencies? Sure, maybe. Is that an excuse to have artificial friction? No. I eagerly await the day when meson or conan or whatever becomes The C++ Dependency And Package Manager.

My other favorite part of Rust is the elitist language features like iterators, immutable borrows, functional programming, etc.

[tragomaskhalos]

Related to this is how easy it is when looking at someone's code on say GitHub to (a) see how the whole project is structured - because it's basically always the same with the familiar landmarks of src/, cargo.toml etc, and (b) to track down the definition / implementation of a type or function (just by applying knowledge of the module system + looking at the mod and use statements). This is a completely different experience from trying to pick apart some C or C++, where you are, essentially, at the mercy of the implementor's idiosyncratic view of how code should be structured, and really need either an IDE or vast reserves of patience to help navigate it.

[asdkhadsj]

While I agree with you, I think you underestimate the number of features that help Rust be great in the face of a Lifetimes and Generics. One feature tends to lead to another. For example, Traits with Associated Types are amazing, but they then lead to a desire for GATs. GATs aren't (in this context) some fancy feature of its own, it fills in a noticeable void in an existing feature, Traits.

So many of these features Rust adds just fill in holes in an already extensive ecosystem.

I agree some feature development could be toned down to mitigate the moving target problem.. hell I think last years poll expressed roughly that. But, I think there's still a ton of features yet to come that merely complete what we already have.