But I've experienced similar things repeatedly. Complexity seems to be tolerated (even vaunted) by the Rust dev community at large. I don't rule out that this may have good reasons behind it (the nature of Rust's natural domain, etc).

I do find the intense advocacy thing singularly odd with Rust. It's not like developers have to be convinced a thing is easy for them to use it. I'm still learning Rust (for reasons). But I don't feel the need to submit to social pressure from Rust advocates to feign ease.

Can you give an example of what you mean by "complexity"? I think this could be an instance of people simply having different definitions.

Without a lot of experience (not to mention vast amounts of memorisation), everything is just hard and slow to get done. And I do mean by comparison with other languages I've used, from Objective-C to Java, from Typescript to Elixir (and many others).

Again, this isn't necessarily a complaint about the complexity per se. It might be necessary (I don't feel I know enough to judge), given Rust's uses and constraints. But the community consistently and obviously denies the difficulty. I think I understand the sources of the denial. But that doesn't make it any less irritating!

This is an answer on the forums to a fairly beginnery-looking question: https://users.rust-lang.org/t/what-does-borrow-mean/81794/3

In what language ecosystem other than Rust would that answer arise as an answer to a beginner's question? Haskell, or a research language perhaps. I can't make head or tail of the Rust Playground example there. In fact if I look through most of recent questions on the Rust forum, there's probably 1 in 10 where I even grok the question, let alone the answer. I haven't experienced this elsewhere. Rust has a culture of complexity, and its community is in a state of denial about it (for I think a fairly obvious reason). Furious denunciations ensue even if anyone dare suggest such a thing!

On the other hand, the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status. I assume that the presence of Cargo in the ecosystem and the mentality that you can just use a crate to do what you want is a big part of this.

I think you may be misunderstanding something here? GCC-Rust would have no reason to import Cargo. Cargo is a tool for resolving and managing dependencies and generating compiler invocations. GCC-Rust is a compiler that would be invoked by Cargo.

> the Rust STL itself is full of bit-rotting functions that have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status.

Rust stabilizes several new library functions with every release. Which ones are you trying to use? Rust is driven by volunteers, and many functions only get stabilized when people ask for them and present concrete use cases.

* The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into. The fact that several new functions are stabilized with every release does not mean that many functions don't sit in the queue for years waiting for stabilization.

Can you clarify which users you mean? If you mean the developers of GCC-Rust, they don't need Cargo because GCC-Rust is written in C++. And users of GCC-Rust would have no problem using Cargo, assuming that GCC-Rust presents a CLI interface that's more-or-less compatible with rustc (which I assume they would want to do, because being compatible with the existing Cargo ecosystem is quite valuable).

> The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into.

The good news is that those functions were recently proposed for stabilization and the ten-day final comment period elapsed as of today with no objections, so these are on track to be available on stable as of Rust 1.66. As for the other functions that you allude to, I encourage you to join the libs-team Zulip and ask how best to proceed on a given API; quite often I find that there's nothing preventing an API from reaching stable other than finding someone willing to do the small amount of labor involved in documenting, writing a stabilization report, and issuing the stabilization PR.

Cargo, NPM, Pip, and other package managers present significant security weaknesses, and many users of C++ today do not work with this kind of flow because of this weakness. The code that Rust and C++ are aimed at is generally more security-critical than most javascript or python code.

Finally, it's great that those functions will finally be marked stable. They were stable as of 2019.

The problem I have with this isn't the specific functions, it's the process. Having functions that are stable, but waiting for years for someone to write a little bit of documentation about their stability is nuts.

I understand that people hate writing reports, but it seems that many maintainers are happy to churn out code for functions and then decide the project is finished before actually finishing it. Anyone else who wants the function is then in an awkward position: Do you want to step on someone's toes and write the stabilization report? Do you want to guarantee the stability of code that someone else wrote that you may not understand? You can't re-write it now - that would be wasteful and petty. So what do you do? You wait for someone else to take the risk.

In the Linux kernel, tons of documentation and reporting about your function being correct and stable are a prerequisite for submitting code, and this seems to work very well at preventing situations where you have lots of 90% finished projects. That is also true of most companies and most other commercially-relevant open-source projects.