It's instead the mass of "programmers" who've spent their lives only using a single language like C or C++ who instead write comments from ignorance criticizing Rust by claiming it's just being pushed by "tech geeks".
I'm not part of any Rust community. I've been out of university for almost a decade now and have been repeatedly burned by legacy C and C++ codebases causing bugs that take weeks to find because of their rarity and non-reproducibility that are inevitably memory corruption issues. If I could swing a magic wand and convert all C and C++ code to Rust I'd do it in an instant. (And I'm a pretty piss poor Rust programmer at the moment, and I'd still do it. I'd rather be learning something that would benefit my psyche and allow me to enjoy my job more.)
It just ruins you over time and makes you wish you never had to work in this business.
And on a more personal level, I dislike the Rust community (and language, eg. for loops depend on trait resolution)'s heavy use of functional, generic, and higher-order function abstractions (rather than explicit imperative code amenable to sequential reasoning). I feel heavy use of generics is confusing in a language used to teach programming to students (and I think usefully learning mainstream programming revolves around algorithmic reasoning from the level of memory and bytes through structured programming, rather than pure functions and iterator combinators).
Not safe in the presence of variant records (i.e. enums in Rust), since one pointer might be used to derive a pointer to a field of one variant, and the object might concurrently be switched to a different variant. This is why Cell<> only relies on explicit get and set methods in the general case, where the entire object gets replaced. It's a well-known problem in temporal safety.
Context: I took C++ back in college in 1999 and 2000. There were students who struggled with it then who dropped CS as a major. Later on I heard that Java took over as a 101 class. Now I think it’s Python.
The beginning of this statement is at odds with the end of it. Anyone who understands tradeoffs won't push anything because they know that which tradeoffs are acceptable is intimately dependent on the problem being solved, and without deep knowledge of the problem one cannot even begin to speak about accepting tradeoffs. Pushing someone who doesn't yet understand their problem towards a solution is the antithesis of engineering.
Moderately experienced code monkeys, who have been around enough problems to see failure, but not enough problems to understand that other people have different problems to solve seem to like to push languages onto other people, though. I'll give you that.
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.
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.
Uutils, helix, zellij, ripgrep, and countless others.
Ive stopped caring (mostly) to convince others of it, but many, many Rust projects are clearly started by very experienced folks that know how to release and foster a community.
Suuuure, some people will complain about the borrow checker, but I think it's people who are mostly inexperienced with Rust. It's not really an issue for anyone after they've played with the language for a while.
Like, these days I rarely have to debug a borrowing errors, and if I do it's a few minutes of work tops.
`xplr` and `joshuto` are clearly thought-out non-trivial TUI file explorers that seem to scale to the naive and a certain power-user type.
`difftastic` is a very cool replacement `diff`.
`jj` is compatible with git, and like git-branchless, but I'll bet on `jj` for a number of reasons. It's also awesome and in 3 years there's going to be some amazing tools built with `jj` and...
(not a daily/semi-daily use, at all, but special mention:) `git-oxide`, I mean, you can guess from the name, the monthly reports show just how incredibly thoughtful the author is and just how incredibly viable and already-usable this project is (especially given the complexity which I really would not have understood without the thorough monthly updates).
followup, there's no reason for this to really mean anything, or for anyone to "believe" me, but I just opened this post on reddit:
https://old.reddit.com/r/zfs/comments/10pdspe/take_your_zfsb...
and wow, what a smart tool, and a smart way to release it. I know how to mount a snapshot, and ripgrep/fd through it, could script that, but making that resilient would suck. The way this is presented is smart. It's a new OSS project, shows example usage in the reddit post. Anyway, I thought of my comment earlier, and of course, there it is, `Cargo.lock`, bias confirmed. And a tagged release. And has a `LICENSE`. And has committed `Cargo.lock`.
For the sake of not replying too much I'll say I'd echo everything spoiler wrote in this posts' sibling comment. And at the risk of coming across poorly, there's something that's a cross of stockholm-syndrome and sunk cost fallacy and it seems like when certain potentially displacing technologies gain more and more steam, there's a louder and louder minority that claim that this new paradigm is just too disruptive and what are they teaching our kids. (oops)
Also, this seems like a classic “Arch, btw” sentiment. Where you hear it over and over and over again, about how the folks who use this one tech are all assholes, but you never actually see the asshole.
For myself and many that I've interacted with, Rust's Borrow Checker and memory system saves me from the PTSD of segfaults and null pointers.
I'd love to see the idea of borrow checking and scoped based memory extended to other languages, but that's what makes Rust great for now.
Today, I wouldn't use new or delete in any C++ program for any reason. Segfaults and null pointers have become extremely rare.
I appreciate that RAII is in C++ as well. RAII is an addition to C++. You can write valid C++ with memory leaks all over the place. This is the nature of being a superset of C. In Rust, there is no other way (outside of using unsafe). It is a language based around compile time memory safety. Segfaults and null pointers aren't extremely rare, they're extremely rare in modern C++ (which is a subset of all C++)
The borrow checker validates references as they are passed throughout your program. You can have either (many immutable references || one mutable references). This may seem simple but is key to the memory safety ideas. The usages of references are validated. Move semantics are checked at compile time.
A lot of people who argue for Rust claim that it is both memory safe and fast, which is well-documented at this point. But it’s not like you’re going to address the actual arguments made in reality, are you.