It's all the stuff that people always mention; they are not wrong. You spend a decent amount of time... conversing with the compiler about lifetimes and, in my experience, even more so about the type system, which is _extremely_ complicated. But you also have to keep in mind that Rust got very popular, very fast, and the tail end of something like that is always a negative reaction. The language is the same, despite the hype roller coaster.

I find Rust's complexity freeing, in that there are often at least a few ways to express what I want, and I can choose the one I feel best fits the use-case and my desired ergonomics. (I also like that there are often ways to express exactly a very precise want, owing well to the Rust principle of "zero-cost abstractions.") However of course, that very same complexity can make it unclear which approach may best serve a given objective, and lead to false starts, wacky implementations, or even giving up entirely.

I'm not OP but here's my disadvantages. Rust is the way I earn my living, and also my open source tool of choice. And my background is 25 years of SWE career:

1. build / compile times can be atrocious

2. crates.io inherits the npm philosophy, which means fairly unmoderated space of third party deps and because the Rust stdlib doesn't have a lot in it, extensive third party crate (lib) usage is strong in Rust. As a result most Rust projects have rather sprawling dependency trees, often with duplicated functionality (multiple Base64, rand, sha256, etc crates). I personally have a problem with this (auditability, accountability, security, complexity etc). Others don't.

3. Despite being nominally runtime agnostic, Rust async basically is tokio and it's almost impossible to use another runtime once you factor in third party deps. In many ways Rust is the language that tokio ate. In fact even if you opt out of async entirely, you often end up with tokio as a dependency simply because the community just seems to expect it.

4. Despite advertising itself as a "systems" language, some basic systems programming facilities I expect from my C++ background are still fundamentally not there. In particular, per-container/struct pluggable allocators still isn't a thing and the feature to add it (allocator-api) has sat unmerged in nightly for almost ten years at this point and it doesn't look good for it landing any time soon.

5. If you're working in the embedded space, there's still plenty of devices that will not have a workable Rust toolchain option yet.

I still choose it for new projects instead of its competitors C++ or Zig. But I think it's important to recognize there are compromises like any other tool.

As much as people might insist otherwise, there will in fact come a day when there are "multiple Rusts" by which I mean multiple styles and ways of doing things -- just like C++. For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there. And I don't use tokio. Though my paying jobs do.

So many great and balanced comments in this thread.

Sure, and I'm available to provide balance commentary for hire, too ;-)

I'm pretty sure you wouldn't like to work on what I'm working on right now though!

> often with duplicated functionality (multiple Base64, rand, sha256, etc crates)

I don’t think this is true unless they differ in major versions no? Cargo will apply semantic versioning and pick the best available given the cargo.toml version constraints.

I don't think they mean multiple versions of the same crate (although can certainly happen too), but rather multiple different crates that cover the same functionality.

this

tho duplicated crates with different major versions through transitive deps is also i believe possible

First 2 are very legit, as a rust dev myself. I wish Rust had a larger stdlib and every argument against it leaves me pretty unconvinced/ feeling like the arguments could just as easily leave us to believe that "HashMap" should not be included (some people believe this), or even "time" should not be, etc.

The compile times are easily the worst part though. They couple poorly with (2).

I feel fine personally without (3), and (4)/(5) don't come up for me.

> For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there.

Same. I basically stick to a minimal `cargo-vet` and avoid new crates. I review new ones. I've chosen to take on a new crate when it's something like "the author literally wrote the spec for this format", but otherwise I'm reluctant.