[infogulch]

I am curious where you get that impression. From what I could see, recent releases have just been "smoothing over pits" / filling in obvious type holes left over from older changes. Changes in rust edition 2021 are tiny and it seems to only exist in order to establish a regular cadence.

[sai_c]

Disclaimer: I've only dabbled in Rust from time to time, but have not written anything serious with it.

Those kind of comments are not based on looking at Rust's features on a theoretical level.

It's more from the viewpoint of "How hard is it to get something (correctly) done". Those impressions are mostly formed either from using the language and failing (or having severe difficulties) to solve a given problem, or being exposed to blog posts describing those kinds of problems.

Rust sure does not have as many features as C++, but it seems that in practice, the combination of available features (and/or the problems those create) is perceived as just as complex as C++. Though not being a fair assessment, the Rust community will have to try fighting this perception, if Rust is not to be labeled way more complex than C++ in the coming years.

[roca]

It is hard to stop people perceiving Rust as over-complex if they are motivated to perceive it as over-complex.

[jevgeni]

I think the problem here is that Rust exposes a lot of additional problems in a domain that are swept under the rug in other languages. I mean, those problems have always existed, it's just we are used to hoping or assuming that the generic solution within a language runtime will save us from them.

[sai_c]

Yes, indeed. Yet, this is the problem to solve.

I don't know if you are using Rust, but what would you say, why is that? Where does that motivation come from?

[roca]

I've been developing mostly in Rust for the last five years. C++ for decades before that.

It is always comforting to dismiss something that you haven't made much effort to understand as unnecessarily overcomplex. I think we're all guilty of that at times.

[sai_c]

Ah, i see. But the systems crowd (I'm going to lump them all together: microcontroller, kernel, high performance networking, etc.) is supposed to be the main target audience. For me it is hard to believe that so many of them just brush it off as too complex on first sight.

On the other hand, maybe those folks decided, after giving it a serious try, it's not worth it. Mind you, that does not mean they are right. But in the end, if the effort for those people is perceived as too high, then maybe, just maybe, in practice it really is.

After more than 25 years as a developer, I learned the hard way, that programming languages, are, in the end, a matter of taste. You won't get someone to use a language, just by citing the feature list. Programming languages are a product made for developers. If they don't like it (for whatever reasons, and yes, these are at times highly subjective) they won't use it.

[roca]

Sure, but we aren't making decisions in a vaccum with no consequences.

If I really like C and I ship a bunch of C code that gets exploited to build a botnet, that decision had consequences. I should have valued safety higher and the fact I didn't "like" safe alternatives was a distraction.