[dbdr]

> I don’t like the Rust culture. There’s no better way to put it. Every time I’ve interacted with them or hear how they talk about Rust, I just don’t like it.

I wonder if it's not that different people have entirely different experiences:

If you are outside the rust community, you'll mostly interact in the context of language flame wars, "why don't you just rewrite it in rust", etc. That is, you interact with the (small) part of the rust community that is most likely to want to dismiss other languages and want to brag.

I consider myself in the rust community, on reddit, the rust forum, etc, and I find it extremely well-meaning, inclusive, supportive of beginners, thoughtful, and generally a very pleasant bunch.

[pdpi]

Zealots are a problem in every community, sadly. Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead. The zealots just don’t understand (or acknowledge) how “all else being equal” does all the heavy lifting.

As somebody who’s fascinated by programming languages in general, I’m quite keen on Zig. I prefer Rust, and disagree with a bunch of things Zig does, but admire the language for trying.

[amiga386]

> all else being equal, most C software would indeed benefit from being written in Rust instead

I don't even think this is true.

You can certainly say "the security of computer systems would be a little bit better if most software was written in memory safe languages" (even more so if you went a bit further and said "with automatic memory management").

However, a lot of software exists and is useful, and the only reason it exists is because the author(s) found a way they liked to express that software.

So, for example, there are millions of companies out there, especially small ones, running all their finances on Excel. Not even accounting software. Excel. I am totally OK with this. I do not need all these companies to rewrite their Excel workflows into frontend applications backed by a relational database, even though that would be "better" in a lot of ways (more robust, easier to backup, easier to bring someone else onto...). Those little business owners understand Excel and build models and count numbers and they're happy with that. If some kind of edict compelled them to use something "proper" instead, they might not even go into business, and the world would lose whatever it is their business does.

The same thing goes for software and languages. Each language, whether it's F#, Haskell, Common Lisp, PHP, ... brings with it its own kinds of expressiveness and usefulness, and ecosystems of programmers and libraries/modules form around it. Some languages are a better "fit", sometimes for the problem domain, sometimes for the programmer's mind, sometimes for community building. It's difficult to compare any two languages because of this, and if you were to say "language X should not exist, all software written in X should've been written in language Y", you have to accept in your thought experiment that were that the case, their is likely a huge amount of software which would not exist just out of the people who made it not being happy about language Y and, if it were the only choice, would choose not to create the software they created in language X at all.

[pdpi]

I think we're in violent agreement, because when I said "all else being equal", I really meant all else.

If a language's mental model doesn't mesh well with yours, that's in and of itself an ever-flowing fountain of bugs, and a legitimate reason not to use it. This isn't a valid excuse to not give unfamiliar languages an earnest try, but does justify different people reaching different conclusions afterwards.

The single most important part of the mental model for programming in Excel is precisely that it takes people who tell themselves they could never be programmers, and tricks them into believing they aren't really programming, so they're "allowed" to do it by themselves. It's an incredibly empowering piece of tech. Rust and Zig and Haskell and all the other languages that excite me personally can never hold a candle to that.

> Each language, whether it's F#, Haskell, Common Lisp, PHP, ... brings with it its own kinds of expressiveness and usefulness, and ecosystems of programmers and libraries/modules form around it.

Preaching to the choir :)

[bmitc]

> and the only reason it exists is because the author(s) found a way they liked to express that software.

In a discussion about comparing two languages, there's an implication there that they found a way they liked to express their idea in a particular language that couldn't be done in the other just as well if not better.

Doing things well in C requires a large amount of things that just don't happen if you're writing the same program in Rust. And Rust greatly enables domain-driven design that basically doesn't exist in any C program.

[Cyberdog]

> Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead.

But all other things are not equal, are they? A vital piece of software written in C that has been battle-tested and optimized throughout its two, three, four decades or more of existence does not magically improve if it gets rewritten in Rust. Not only does that not make sense in theory, we've also seen it in reality with the issues with the coreutils rewrites.

You can make a solid argument that new software written completely from zero would be better served by being written in Rust than C. But the "just rewrite it bro" types are so incredibly obnoxious and out of step with reality.

[pdpi]

Yes, that's exactly my point — they're holding on to what is arguably a tiny kernel of truth, and blowing it way out of proportion. And, to be clear, "zealot" isn't meant as a compliment.

And yes, coreutils is a great example of what I mean. The GNU project was always meant to be the basis for a production grade operating system. I mean, GNU Hello is just a hello world program, and its source weighs in at 707kB zipped (or 3.6MB unzipped). The purpose is having a trivial application that can serve as reference for all the standard practices of the GNU Project. No amount of writing things in Rust can replace the engineering mentality that leads to GNU Hello existing. In comparison, as I understand it uutils was first and foremost an educational project that got coopted into being used in production. Things are very much not alike here.

[eklavya]

If you don't like rust for whatever reason, use any other memory safe language. If you need more convincing that bugs and vulns are dropping let and right from decades old battle tested software, ask anyone with access to frontier ai sec models.

[beanjuiceII]

I've had rust developers quite often..tell me that it's immoral to use a language that doesn't have memory safety

[synergy20]

The "Rust Evangelism Strike Force" is so annoying and it becomes the major reason I don't want to have anything to do with the language, yes I know it's strange.

Almost all HN software related discussion will have some Rust folks saying 'yeah I have a rust project for that', or 'just write this in rust and it will be better', so annoying after seeing those each time, it's like the house-window sales guy keeps knocking my door every day and never goes away.

[quotemstr]

Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users?

Me: You're right. Java has come a long way. Let's download...

Rust: No! No no on. Not like that!

---

Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn GC. Rust's safety-plus-malloc niche should be much smaller than it is.

[AlotOfReading]

If you're manually calling malloc in Rust, your code is almost certainly wrong. It might be called as an implementation detail when you create new objects, but std can generally be used as if it were managed automatically.

[quotemstr]

I'm using malloc as synecdoche for all forms of allocation, including Arc<Box<T>> stuff.

[tjoff]

GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance.

For scripting etc. it is perfect though.

[quotemstr]

Even if you're one of those people who believes the highest levels of performance require manual memory management (I'd disagree, but whatever), you'd do well to consider the performance of real-world GC against performance of the Arc/Box/dyn/clone-heavy "high-level Rust" [1] [2] that people and LLMs usually write.

Maybe you can write a carefully-tuned arena-and-slotmap that beats the pants off any GC. GC doesn't have to compete against P99.9 systems programming excellence. It has to compete against an endless soup of Arc, Box, and clone, and it will win this match without breaking a sweat.

[1] https://hamy.xyz/blog/2026-01_high-level-rust

[2] https://llogiq.github.io/2020/05/30/hi.html

[tjoff]

Performance is not even a factor in my argument.

[wild_egg]

Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well.

The biggest difference is the failure modes. If I'm not thinking about memory, my RSS is higher or a bit of extra CPU time goes to GC. Both of those are radically better than UAF or buffer overruns. Good trade IMO.

[tjoff]

I didn't say that. But if you think about memory then GC does more harm than good because you have no help from the language.

A GC is not the only fix for UAF and buffer overruns...

[pjmlp]

Depends very much which programming languages we're talking about.

There are enough managed languages with knobs allowing to do C like coding when required to do so.

[rsyring]

For a lot of programming tasks, HAVING to think about memory is a disservice.

That's part of the reason why Python, go, Ruby, etc. are so popular.

There is no one right answer, it's very dependent on what's being built and where the ROI for the programming effort comes from.

[tjoff]

For some tasks, sure.

But you still have to think about memory in those languages.

[fp64]

I also do not like the Rust culture. I think the core problem is that it is so centered around identity, and this leaks into how the arguments are presented and how "outsiders" are judged. Which your example illustrates.

[blanched]

I don’t really understand what you mean. How can you have a community without identity? Isn’t that just a category? i.e. “a person who uses rust” vs “a member of the rust community”. There’s nothing wrong with either one, but the latter tends to define the culture.

[largePanda9]

What would you say is a good starting point for learning Rust? I’ve been curious about it for a while, but coming from a mostly Python, I’m straight up intimidated and fear wasting time trying to learn something I won’t really ever fully be competent in…

[mekoka]

The article had great advice on this actually. When asked how to get into C, or whether it was more advisable to learn Zig instead, Mitchell suggested that

It’s more important to learn how computers work and make the language just a means to understanding how they work. [...] even in this age of higher level abstractions and web development, it’s still important to understand the basics of CPU scheduling, memory, cache hierarchies, file systems, disc and file access. When you work directly above the syscall layer, whether in C, Zig or Rust, it really helps you understand what’s happening[...]

[jjice]

The official rust book (officially available free online) is the way to good. So good I purchased it when it went paperback. It's a top tier language book.

[jononor]

Writing a Python extension would a good way to dip your toes into Rust, and also add a useful skill to Python programming (writing performant extensions). PyO3 is the main project, and the topic has been covered in several talks at Python conferences (check Youtube).

[ktimespi]

It does need quite a bit of time to be productive with... That being said, Rust by Example is good

[hansvm]

Rust was ~70% of my last job, and the other Rust engineers there were very competent -- large volumes of high-quality, high-impact code. In my rust community interactions at the time, also interactions with my colleagues, I definitely noticed some unsavory trends. An example pattern is:

me> This [API | language feature | whatever] seems harder to use than it should be.

them> No, it's actually not.

me> Here's irrefutable proof.

them> Well at least you have memory safety.

me> But...you can have memory safety without this thing being a dumpster fire. Wouldn't that be better?

them> <no concessions, Rust is perfect>

After a few conversations like that, I've literally had those same otherwise high-caliber engineers spend days wrestling with the "easy" thing we were quibbling about. I'm sure it's not intentional, but it comes across as religious gaslighting.

And maybe I just interacted with the wrong people at the wrong point in Rust's lifecycle and the community is mostly very positive. I see enough people with experiences like mine though that I'm not willing to believe it's a truly miniscule fraction of the language's discourse.

[torginus]

Its academia. Rust is admirable for having been able interesting programming language research into a mainstream language, but this had the implication of bringing the people who did said research with it into the communities.

It used to be that programming languages were mostly boring and predictable, with maybe questionable semantics (const etc.), but generally that messiness meant they were good enough at getting the job done.

PL research and theory focused on mostly FP, Ocaml family and other functional languages, with things like advanced type inference system, based on postgraduate category theory. These people have fought endless and bitter mental battles with each other, a glimpse of which occasionally leaked to HN. Some paper about a noteworthy discovery in solving a problem incomprehensible to the general public. Some guy complaining about how he tried to educate average programmers about how unsound their programs were, and being taken aback at how these people didn't want to be saved from their own stupidity. Some article complaining about how if every programmer was just 15 IQ points smarter, they'd be all doing FP. But mostly this community kept to themselves.

Thanks to Rust, all these ideas have found purchase in real practical software. Now the academics get to torment themselves with the moral duty of saving the everyman from using less theoretically sound programming languages.

(Disclaimer - I don't hate Rust, I think it's great they made this breakthrough from academia to regular boring programming, but they need to respect the nuance of the world that exists outside the walls of research institutions)

[asa400]

I've been using Rust in anger since ~2018 and I guess I've had completely different experience, especially compared to what I was mostly doing before, which was Scala.

Scala (the v2 series, I haven't used v3 at all) was, to a first approximation, a language of, by, and for graduate students in language research that accidentally escaped the lab and briefly took over the data engineering space. Multiple competing category theory libraries, vicious fights about which was more pure, continued debates about the beauty and confusion of implicits resolution, the list goes on.

Rust seems downright blue collar in comparison. So much of the Rust I've written and the teams I've been on, and the open source we've used has been exactly the kind of stuff we would have used Java for 15 years ago. Boring practical stuff. Same goes for the community interactions. "Here's how to get this thing working", "here's a better way to do this", "maybe you didn't know but here's a cool way to speed up that section", etc.

Sure, if you go into the development process of The Rust Language Itself, people are talking about compiler minutiae and using datalog to do type resolution, but that _really_ has not been my experience as a user. Me and everyone I know use Rust like the Golang people say they use Golang.

In fact the crux of the difference between the Rust community and the Scala community has been Rust's continued obsession with developer experience/user experience (whatever you want to call it). The error messages, the tooling, etc. Scala had none of this. A disproportionately significant section of the Scala people were obsessed with type theory, quite often to the detriment of usability/programming experience.

I respect your experience with the Rust community but I haven't had this experience at all. Totally unrecognizable to me.

[pjmlp]

Rust is becoming the chosen language for those that would have previously used Haskell, OCaml, Scala, but now get to use something with more mainstream mindshare.

It isn't very hard to find folks misusing unsafe to mean something else other than memory safety, or their own ZIO like frameworks.

[asa400]

Not sure I understand the point you're trying to make. Can you rephrase?

[pjmlp]

Easy, some folks write Haskell or Scala in Rust, because it allows them to reach a wider mindshare.

So they write their monadic and effects frameworks in Rust instead, and use unsafe to mark methods that might be dangerous, regardless of related to possible memory corruption or not.

[brabel]

Rust didn’t start in academia! It was a practitioner’s pet language until Mozilla started sponsoring its development. It’s actually the exact opposite of an academic language like OCaml and Scala, which were started by researchers in universities. Rust did incorporate some academic ideas like the borrow checker and algebraic data types, but the former was already being used in a precursor language, and the latter was almost becoming mainstream (which it is now, Rust helped a lot with that but was one of several languages that had it).

[sph]

It’s like that joke: I admire Jesus Christ, it’s his fan club I really can’t stand.

You can substitute that with Rust and it sums up my feelings. The language is great, the obsession with static typing and memory safety from its fans, as if it’s the panacea to all problems in computing, is obnoxious and smells of inexperience. It’s not a coincidence that Rust these days is baby’s first low level language, so you get a lot of strong, uninformed opinions on software design.

[tialaramex]

Ghandi wasn't making a joke when he said: "I love your Christ but I hate your Christians because your Christians are unlike your Christ.". By this time Ghandi had spent some time reading about Jesus, and interacting with Christians and so this contrast will have been very stark.

[RamblingCTO]

I had a senior dev in my previous team who pushed to write microservices for a web SaaS in rust. We already had some in Go and it worked phenomenal. Easy to learn, write, maintain, effing fast and wonderful tooling around graphQL. His only argument was "Rust is a better language and it's memory safe". That sums up the interactions I have with rust fanboys quite well. No one in the team could do rust, the added headaches around memory safety have no benefit for services like this at all and there's no tooling or hiring benefit as well (quite the opposite I guess). There wasn't a single sensible argument to be made for rust imho. I overruled him on that of course.

[up2isomorphism]

You are exactly depicting the problem of the rust culture.

[secondcoming]

I just think it'a visually unappealing language.

[larme]

This description sounds like a cult.