It's not the same though. The breadth is wildly different. In the case of things like JavaScript, C, or Go it can be said that you use -most of it- in a day to day to basis, sure, not the most magic, deep crap, but not the same can be said about C#, Rust, C++ etc on which you have a lot of features simply not used.
Rust hasn't grown 17 ways to initialize a variable yet. Most projects use most features.
When projects choose a subset of language features, it's dictated by their needs (like embedded programs disabling the standard library, or safety-critical libraries forbidding "unsafe" code out of caution). There are some people who vocally hate async, but their complaint is usually that everyone uses async even where it's unnecessary (meaning that it actually has very broad adoption).
This feels very different than having an unwanted C subset, some '98 features that were replaced in '11 and '13, with fixes for them in '20 and '26 and then projects taking years to settle on a new baseline, and still bickering whether exceptions may be allowed or not.
Rust has "editions" that let new projects disable old misfeatures (which it hasn't got many yet). Rust ecosystem is fully on board with the latest version.
Bootstrapping of the rustc compiler from scratch is a very different experience than using the language as a user. Bootstrapping requires building a C++ mrustc proto-compiler, which is where the tons of flags are needed. The rustc compiler has a custom multi-stage build system to make it and its standard library built with itself, which multiplies the time it takes. It's designed to be consistent and optimized, since most users download a pre-built binary.
However, once you bootstrap it (or willing to trust someone who did), it's a breeze to build Rust projects with Cargo: `cargo build` just works with no extra flags for the majority of projects. The only finicky builds are ones that rely on C or C++ deps.
Calling your users idiots is not a good look for a maintainer. I don't know offhand what distro you maintain but I sincerely hope I never have to deal with someone this hostile.
You're harshly judging the entire language based on ease of compiling a 3rd party C++ compiler and the C11 code it emits. These gnarly build commands don't even come from the Rust project, and aren't using the Rust language.
(I assume you use mrustc, and you're not going the masochist route of recreating all the development steps starting from a 15-year-old Ocaml-based prototype of a language that wasn't Rust yet).
It's fair to say that bootstrapping of Rust sucks. It really does. The non-Rust bootstrap compiler doesn't get even a fraction of the polish that rustc and Cargo get. But it's not representative of how Rust and Cargo work for basically everyone in the world except you (and a couple of other maintainers who chose to do an independent bootstrap from scratch). Bootstrapping is a one-off pain, and then building Rust with a Rust-based compiler is nice and easy.
It'd be nice to have a cleaner bootstrap story for Rust, but it will take a while (waiting for gccrs C++ reimplementation to advance enough to replace mrustc).
Rust is pragmatic about its implementation. The goal isn't some ideological purity (despite the reputation Rust has), but to empower users to make safe and efficient systems software. LLVM works well for that, so replacing it isn't a priority. The cranelift backend exists to make debug builds faster.
Yeah, no. That is not a fair description of Rust. It's got far fewer mistakes than C++ and, get this, it has a mechanism for tentative features that can get revised and fixed based on usage experience. It doesn't always work especially for far-reaching decisions (I hear that async is considered problematic), but it prevents a lot of stupid mistakes that C++ is carrying along forever - with a few exceptions (e.g. garbage collection support, extern templates) and some very notable inclusions (the kind of botched module system, suboptimal unordered_map, std::string which is more of a byte/word array).
I like C++ because I like the fairly unique high performance low level feature set, not because I particularly like most of the detailed design decisions that went into it. Rust has the same goals, but is better thought out IMO. I'm sure that I will find some more trouble in Rust as I use it more, but so far the impression is quite good. I have become pretty good at writing C++ code that works after fixing one or two stupid bugs, and that works even better in Rust, mostly without the stupid bugs because you can't forget to null-check a pointer to another subsystem while starting up etc.
You're naming and lambasting multiple different technologies and their communities without justifying why they are so bad. Few people use C without knowing about the threat of buffer overflows or invalid pointer dereferences, and C can be used productively in spite of these obvious flaws. Instead of trying to drive people away from what they do, if you seek understanding then you should allow others to justify their reasons. If you only test your understanding against your understanding, you're not making an assessment at all. You can find and talk to many smart people here and elsewhere, if you so desire.
You're saying "force into this and that" like there's some evil omnipotent entity compelling people to write Rust against their own free will lol. What do you mean by forced? People enjoy writing Rust, so hence it's being written in other projects.
Saying LLVM is written in C++ doesn't really bring much to the discussion. It was released 25 years ago, and C++ was released 40 years ago (hey, it's older than me lol). Rust was released like 10 years ago. So, yeah... I guess it makes sense that they used C++ back then? I'd have picked C++ back then too.
I've written C++ for about 15 years, and I don't have a blind hatred for the languge, but going back to it doesn't fill me with joy either, especially after having written Rust for the past few years.
The module system is more intuitive to use than the preprocessing file concatenation. There's also a nice package manager. I know some people find this a downside though, but I prefer it to fighting autoconf or CMake.
Syntax highlighting for Rust code doesn't lag 10+ seconds.
Symbol search doesn't require three different third-party tools to work.
Documentation is built in AND nice (no doxy doesn't count as nice, not in any universe).
Testing is built in. There's a (mostly) homogeneous build system
The borrowing rules are things you think about in C++ anyway, but Rust just makes it so you don't forget them; there's some clang lints that help with this in C++ anyway.
The syntax, while sometimes a bit noisy, is nicer in the average case, but C++ has been getting better in that regard.
There's much fewer API gotchas with Rust than with C++ (from the top of my head: closures, std::optional, std::variant, iterators, {a..z}values, a managerie of constructors, SFINAE, all these things have pain in the ass built in as a core principle). I also despise function overloading.
The macro system, while I don't like it too much in Rust, makes things
The type system in Rust is so much better it's not even comparable.
But anyway, Rust has some downsides. It requires you to change how you design solution sometimes. The compilation times are crap (but the compilers also does so much).
The military isn't going to allow C++ anymore due to it being a massive security hazard. You can't get away with buffer overflows, use after frees, data races, etc. forever.
Due to an evil entity called the military industrial complex, you are going to be using Rust in the future.
