Rust's safety in practice is a cultural phenomenon. For example, you could (using "unsafe") write an implementation of Index for your Rust type which has the exact same unsafety as the typical C++ operator[]. In Rust the community will insist your type is broken, an unsafe Index is wrong, whereas in C++ most of the community would see that as fine, why should operator[] be safe? After all the standard library's types behave this way. Culture is the only difference here. So, in fact culture is crucial to Rust's success.
Now, you could try to argue that it's unrelated, that there's this nice neat line between some cultural decisions like "Is it OK not to exhibit type safe behaviour?" and some other cultural decisions like "Is it OK to make racist jokes in my documentation?" but turns out that wherever you think that line "obviously" goes lot of people disagree and you're going to spend all your time fighting about that if you insist it's real.
Given how important the programming culture surrounding a programming language is to determining how day-to-day usage of the programming language actually plays out, programming language features should not only be judged on their technical pros and cons, but also on the kind of culture that they tend to promote, which is very much an extrinsic, social thing.
There are certain features that tend to draw in certain kinds of programmers and repel other kinds of programmers. Those programmers will in turn pull in all sorts of other technical baggage that has a variety of other technical knock-on effects.
Hence when creating a new programming language, we should think carefully about what kind of culture certain programming language features promote and what kinds of programmers those features would attract and repel, because those can ultimately twist the programming language in ways far more influential than any of its original features.
The Rust community reminds me a lot of Bitcoin. You cannot say anything without a reply-guy telling you why you're wrong, even if it's just something minor. I already see all kinds of "it's in the kernel" posts in here too. (Hint: it's "in the kernel" is actually an argument against its use for, say, the web--not for it.)
This is just another instance of the tired cycle of people not understanding most problems in tech need evolution, even though the big things come from revolution. Just look at how mad people get about Apple's "forced obsolescence." You cannot start everything from scratch even for revolutionary gains.
Are there revolutionary gains with Rust? Well, I don't think it should be that hard to make revolutionary gains over a language that's the same age as I am. It would probably be better if everything was written from the ground up, but unless AI does it for us, that's a lot of wasted man-hours.
Apple still hasn't rewritten its entire stack in Swift, much less its kernel, and no one in the industry moves much faster than they do.
I would definitely consider starting any PC-based project (Rust doesn't very many platforms) that I might have used C++ or C for in Rust. And I prefer to used either a very low level language or a very high level language or two together (e.g., asm libraries with Python) and maybe one day Rust will work for me for that, though it has a huge runtime too. Mostly that doesn't matter.
I just try not to blame the language and it's good features for the obnoxious reply-guy cults that surround it. There are worse languages with good communities and definitely worse communities out there.
But no, I don't want to rewrite my MODplayer from 1990 in Rust.
I overall agree with you and there is no reason to rush switching languages for already established projects, but not even for new ones. But I don’t think that this quoted part is really true about the Rust community. Sure, it has a very vocal minority you hear the most which might fit your description (it’s always those we see first), but I find the more general community very well-versed in low-level programming, more often than not having a strong C++ background and/or some advanced FP knowledge, which is great. I regularly visit r/rust even though I don’t use the language too much, simply because the quality of discussion on certain issues is very high.
Yeah you don't say, it's huge! Like maybe just a little bigger than C runtime. Unacceptable!
In a language like Java of course the entire Java Virtual Machine is a runtime. There are lots of nice things to like about this, but it's pretty heavyweight. In C and Rust the usual application software is built with a runtime, it just doesn't do very much. For example the runtime makes the world for your software hospitable before your main() function executes and it needs to arrange that atexit() work for example. Rust's runtime does a little more than C's but not a whole lot.
Both C and Rust have a mechanism to write software for an environment where you just wake up naked and setting up even the basic hardware is your problem, as might happen on a tiny embedded SOC too small for an operating system - C calls this "freestanding" and Rust calls it "no_std" but that's not the default.
The new complaint your have though is about binary size - your Rust binaries are big often because of mono-morphisation, a compiler optimisation pass which converts all the polymorphic functions used in your program into distinct instances of that function for each type used, possibly inlining some of them where they're used; and because it's statically linked so the binary ends up with all this stuff in it even if that same stuff would be used by other binaries. It's not big because there's some massive runtime living in the binary.
Even Dr. Dobbs Journal, The C/C++ Users Journal, C++ Report had enough articles regarding safety in C++ applications.
Somehow this culture was lost, maybe as those of us that cared got focused in other languages as well, so now the hardcore performace about anything else are the majority and security conscious people have an hard time making them realize security matters.
Every brand/product/service/etc is trying to create communities around themselves, with fan clubs, VIP memberships, social media groups, email lists, Zoom/in-person conferences/webinars, etc.
It used to be you had to have a ton of reach and value to pull those off before the internet, now every project has marketing and social media people doing the same thing online.
Delphi versus VB, VB vs C++, Pascal vs C, C vs C++...
At the same time - it takes all sorts to make a village, right? Those superfans of this or that language, library, database, whatever.. I'm glad they exist in the world and share their knowledge.