Definitely isn’t one of those things that can be solved, but it’s helpful to be aware of and process on that basis. I think some personalities are likely disproportionately vulnerable to this behaviour, but I think it largely has a positive core of enthusiasm. It’s probably more a matter of those individuals growing in self awareness.
Perhaps we saw a big wave of that with rust because it meant a lot of things to a lot of different people, some more equip to express their enthusiasm with some self control than others.
This rings very true, and I've actually disadvantaged myself somewhat here. I was involved in projects that made very dubious decisions to rewrite large systems in Rust. This caused me to actively stay away from the language, and stick to C++, investing lots of time in overcoming its shortcomings.
Now years later, I started with Rust in a new project. And I must say, I like the language, I really like the tools, and I like the ecosystem. On some dimension I wish I would have done this sooner (but on the other hand, I think I have a better justification of "why Rust" now).
I never fell in love with Rust or got particularly excited about adopting it. But, I just don't see a serious alternative (maybe Swift is fine for some cases but not in my field).
I believe Google's Rust journey was even more closely aligned with Ladybird: "we want memory safety, but with low impedance mismatch from C++". After like 5 years of trying to figure something like that out they seemed to go "OK actually fuck that we just have to use Rust and deal with the challenges it brings for a C++ shop".
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.
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.
And experience doesn't equal correct decision making. People just get traumatized in different ways.
Problem with community is it has experts and groupies mixed in. Ideally experts can talk somewhere and groupies can go somewhere else and talk about funding RSF etc. but now is unnecessary. Expert is available on demand via chatbot.