I'd drop the "long-lived" and "short-lived" from the first two points. Rust is great for long lived programs, and is extremely clunky for managing any kind of object graph in general. The lifetime of the program has little to do with it, so I'm confused by those qualifiers. I've written plenty of Rust software that has run uninterrupted for years.
I've seen way more people complaining about Rust evangelism and toxicity than I've seen of Rust evangelism or toxicity itself, especially here on HN. Even "Rewrite it in Rust" is something I've mostly only ever seen as a denigrating joke (and usually in response to a project choosing to be rewritten in Rust, not even to calls to rewrite something in Rust). I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
> I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
Doubtful. If you're running a somewhat known FOSS C or C++ project, chances are you've had to close issues from Rust fanatics aggressively urging you for a rewrite, and shaming you if you object. Nothing has changed in that regard.
I'm glad you've been spared. That doesn't really negate all the negativity and outright harassment that lots of people have experienced with the Rust community.
I think the best example is the continuous vandalization of cppreference [0][1]. I've never seen such behavior from another language community. There's also continuous mocking/brigading campaigns organized on reddit and mastodon.
"Managing any kind of object graph in general" is just a hard problem. It's what tracing GC was actually invented for! (And indeed, that is still the only one-size-fits-all solution.) It's not fair to blame Rust for surfacing the issues instead of just sweeping them under the rug and letting them blow up in production.
IME in the last while on HN the Rust Evangelism(TM) debate has been brought up either unprompted or because someone argued that Rust was objectively better on some metric (like memory safety compared to another language). In the latter case someone says something that can be argued on its merits but then someone else decides to tone police about “evangelism”.
In this thread there are two Rust subthreads: someone brought up (and was downvoted) “why not Rust” out of nowhere (evangelism) and this one where we are discussing Rust Evangelism because GP quoted Kling on some separate tweet.
So yes. We mostly seem to discuss Rust Evangelism as a meta thing. Something that has supposedly definitely happened, or is happening somewhere else, just rarely right in front of us in the discussions at hand.[1] I think that qualifies as a meme.
As someone that likes Rust, but is decades away from the days I identified myself with any specific language, the Rust Evangelism Strike Force are the ones that spoil the party.
That is exactly the way to put off people, that initially could even be welcoming to hear about what the language is all about.
I realize this is not what people generally are referring to when they complain about the Rust community, but this is the part that annoys me.
Feels like every damn day I see people preaching the Good News of Rust, pointing to things as being the unique and sole property of their preferred language. Except those things have been around for ages, in other languages.
Memory safety? Invented by Rust!
Algebraic Data Types? Invented by Rust!
Funadamental FP constructs? Invented by Rust!
High performance? Invented by Rust!
If instead they just said that they enjoy having all of these things in a single language, well great. But instead it has to turn into a preach fest.
Concurrency? Invented by Go! (quickly corrected by Elixir/Erlang strike force, but these, just like Golang, have worse throughput than a particular C family language I have a soft spot for).
Apologies, could not help myself as this response is amusing if sadly accurate (I do like Rust, but blind hostile evangelism tends to create the opposite to the desired outcome).
Elixir strike Force member here. Minor correction, concurrency wasn't invented by elixir, it was just perfected by it ;-D
(That's a joke for the record. Elixir mainly uses erlang's stuff, and it's based on the actor model, which was not invented by elixir or erlang. I do personally love it though, I believe it to be a great implementation.)
> - Clunky for long-lived programs that maintain large complex object graphs
Interesting observation...I have the exact opposite experience. Rust is especially amazing for long last program because you spend twice as much time developing it and then forget about it for the rest of your lives until you have to change something. And just by browsing the code, a flood of contexts come in because its expressed in the language fairly well (This function returns Option because ...., this function is generic over Read because ...)
I love Rust but have to agree that there is a lot of truth in all of those. The Rust community really should take a look at more welcoming and diverse communities like the Ruby and PostgreSQL communities. Not sure though what can be done to make handling long-lived state less clunky.
I think a lot of this is just rumors and maybe one or two high profile people. When I go to discord servers for rust and rust libraries, the help I get is as good as, if not better than support from companies I literally pay.
For years, whenever there was drama and shit-flinging in the OSS world, i looked up the people causing that on github and blocked them. Github has this feature that it warns you when you look at a repository where people you blocked contributed.
If you keep such a list, you'll easily recognize projects you better stay away from. For me, this was one of the reasons to keep away from Rust.
That sounds flawed to me. A large block list will disproportionately warn you about projects that are more open to any external contribution in general. Guilt by association is a weird standard for FOSS contributions. I certainly don't review the external lives of contributors on my repositories.
My point was just about my actual experience with the community versus what everyone says about it. There is a lot of excitement I've noticed which seems to bother some people but I've never had anyone outright call me an idiot or anything and I always get help when I ask for it.
Interesting re complex projects. Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects, maintaining state etc. I think this is due to the strict type checks, the helpful compile errors, and the ownership system. Maybe also due to the robustness of what I call struct-and-enum-oriented programming.
I have plenty of my own beefs with rust that I won't go into here, but... it comes out on top for complex projects.
> Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects
In my humble experience, Rust gives me great confidence that my refactoring will likely be correct, but the type system makes refactoring anything moderately complex very difficult. I tend to paint myself into corners, and the compiler, in it's religious oath of correctness, won't allow a mortal like me to get away with it.
I guess you can dismiss that as a skill issue, but Rust feels like a language that is very tough to iterate with. It's probably something I will reach for when I'm sure of what exactly my program will do, and how it will do it.
It's definitely more clunky for complex object graphs. Making a useful directed graph with cycles is pretty annoying. Not impossible my any means (I'm currently working on a Rust project for audio graphs that allows cycles), but not nearly as easy as a GC language would make it.
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
To rust purists the latter should be solved through composition of many of the former. This is what happens when constantly going on about the evils of state becomes one of your cultural norms.
That said I recently poked swift for non mac use and was not impressed by the status quo, and am not sure Apple are committed to the exercise. The core language is very nice though.
I wouldn't say all the Rust community is toxic. Then again, I'm not sure which Rust community he's referring to, I'm sure there are some toxic ones out there.
How is that related? What does it have to do with Rust? If anything, I'd say it shows that social media (and microblogging platforms like Twitter and Mastodon in particular) tend to be politically charged, toxic, and dogmatic.
I think it has nothing to do with Rust; probably someone first found it who just so happened to be part of the Rust community, and since the Rust community is full of 'the type of person who would be offended by such an interaction' (basically any queer person) there was naturally an explosion about it.
This is such a weird thread, sure it's a nit but grammatically a person of unknown sex should be either "he or she" or "they." And the latter is by far the preferred form by English writers regardless of political affiliation. It didn't become a political thing until Andreas made it political.
It would have taken two seconds to be like "+1 Good catch man, merged."
It could be an age thing. When I was taught grammar 40 plus years ago, for someone of indeterminate sex, “he” was taught as always appropriate, “he or she” was a somewhat clunky alternative that was situationally appropriate where you were stressing the gender neutrality, and “they” was just simply bad grammar which would get you bad marks. I’m honestly not sure when that changed.
Indeed. I was taught very directly that the singular pronouns were he, she, and it. The plurals were we, you, they. So grammatically if you were referring to a singular person of unknown sex, then you should use "it" .
Obviously using the pronoun "it" at some point became offensive, so is highly not recommended. But, (probably after having drilled into my head repeatedly that "they" is a plural) it seems very incorrect to my ears when "they" is used to describe a singular person. It also unfortunately comes with ambiguity sometimes. I've had misunderstandings where I used they as a singular pronoun to describe someone of unknown gender, and the person I was talking to took it as a reference to a plural, which at best creates confusion, at worst misleads.
Language is an incredibly hard problem, and it certainly doesn't help that as youth, we are drilled with supposedly objective truth regarding language, when in reality it is far less defined and more nebulous than than the teachers would have us believe. The generational gaps can already be tricky to navigate. Having different ideas of objective truth, especially regarding language, certainly does not help.
Because this often ends up with people talking past each other, never until a few years ago did anyone use singular they for a known, specific person. Shakespeare used it for unknown or nonspecific people.
In casual use, yes. In formal writing, the broad switch to acceptance of singular "they" is only about 15 years old. Up until that point it's the sort of thing that would be flagged by an editor, or lose you marks in an English paper.
I'd be shocked if that were universal over that time, given that even formal language has undergone many changes in attitude. Over hundreds of years, I bet that in many times and places it has not considered it a problem, particularly given its use in the King James Bible.
“They” is particularly convenient when discussing about people over the internet, because not only we don't have to assume the person's gender, but we don't have to assume if it's an individual or a group either.
And tbh using gender in pronouns is artificially annoying, and it's good to see English has a way out of it, like it got rid of giving genders to common objects like most European languages (“Non, it's La chaise, chair is feminine in French” -_-').
Languages hold complexity in different areas, but that doesn't make it artificial. Grammatical gender (and noun classes more generally) may seem redundant, but redundancy in language is quite common. It helps disambiguate, as it turns out speech (especially, but writing too) is a very lossy method of communicating.
(You seem perfectly happy distinguishing between animate/inanimate nouns and choosing "it" or "he/she/they" -- that's a difference not all languages make, but should we get rid of it in English too?)
1. "it" does not distinguish between animate and inanimate nouns:
The baby grunted again, and Alice looked very anxiously into its face to see what was the matter with it. — Lewis Carroll, Alice's Adventures in Wonderland
But he [Jesus] said to them, "It is I; do not be afraid." — John 6:20
2. gender distinction is artificial because it's not based on anything real, rather it's based on whether the "vibes" that a person (or an inanimate object in European languages) that you're referring to gives off are more feminine or more masculine. this "redundancy" creates all sorts of trouble for folks who are not comfortable with the "vibes" society assignes them with a particular gender at a given moment. the problem here is not that the speech is lossy, but that this particular "feature" of language demands that you convey the person's identity when it's almost always irrelevant in a way that's exclusive to gender (thank God nationalism wasn't invented when the language was forming)
1. Yes, as with many "rules" in language there are exceptions. I would find it a bit odd to refer to a baby as "it" in (current) English, though I do admit there are some situations where it wouldn't feel as out of place.
In my read of the Bible quote, it's not really referring to a person as "it" in the same way.
2. Grammatical gender has nothing to do with the "vibes" of an inanimate object - it's quite arbitrary, really. The problem you're associating here is much more with gender in humans, but we were talking about the grammatical construct applied to objects (like a chair as the grandparent mentioned).
So, as far as I understand it, gender pronouns are typically for referring to individuals. This means that whether to call a baby, or animal, by gender pronouns or object pronouns varies depending on the expectation.
('gender pronouns' includes singular they/them, which is a 'gender pronoun' in the way that it perhaps, if you will, implies the 'gender' of 'neuter'...)
I guess a generally understood term for this would be "humanization", although as someone who identifies non-human that still sounds somewhat exclusive, but regardless, that is what I generally observe to be the difference.
So, it's possible to refer to a baby or an animal as an object, if, in doing so, you intend not to assign that object any individuality; in other words, if you're referring to it in a non-individualistic way.
e.g. "I needed to change its diaper again today" ("dehumanizing"; I guess shows a lack of empathy, but not everyone necessarily feels empathy for the baby before it is more markedly an individual)
It's also possible to refer to a non-individual (such as an inanimate object) as an individual, which, in doing so, typically implies that the non-individual nonetheless has some sort of individuality or that you're specifically assigning it such.
e.g. referring to ships / other vehicles using 'she'; also, giving everyday objects individuality is a relatively common part of Japanese culture (which is part of why Apple's recent "Crush!" ad upset so many)
Typically, it's respectful to refer to people as individuals because they are. It is "dehumanizing" to suggest otherwise. (seriously, is there a better word for this?)
Some prefer to be referred to as objects instead, though; I know at least one like this. But those will typically specify it in some way, and it's rude not to refer to any one as an individual unless otherwise specified.
> not only we don't have to assume the person's gender, but we don't have to assume if it's an individual or a group either.
as someone with DID (formerly called Multiple Personality Disorder) this is actually kind of a nice bonus. (though people still often use he/him pronouns to refer to specifically me, which is fine)
Seeing this right now single-handedly turned me off from the project. Of all the possible (and more plausible) conclusions that the maintainer could have had, they deduced it to be political (which is arguable) and immediately became extremely defensive. Apparently women don't exist. It's an absolute failure of one's responsibilities as a maintainer -- arguably as a person -- to treat someone's goodwill with such disregard.
Ladybird and Serenity have a policy of not allowing any sort of expression of or reference to someone's sexuality or gender identity, as this is deemed "divisive" or "politicising". Rust does... not have that.
You are right. I don't in fact know if that's what he means by calling the Rust community "toxic".
I've never seen anything like a bigoted word attributed to Andreas, by all appearences he is one of the most caring people in open source, and his character is obviously a big part of Serenity's success in attracting followers and contributers. But he does seem to be very insistent on "having nothing to do with the issue" (of inclusivity). His stated goal is to make a welcoming and inclusive environment, and ultimately I just think letting Pixie Ada put pride flags in xer bio will be more succesful at that than a don't ask, don't tell policy that seems mostly geared to not bother people who happen to fit in by default.
Not like that. A pull request that replaced "he" in documentation with "they" was closed with the comment "This project is not the place to advocate your personal politics".
Yeah, that was a pointlessly rude way to close the PR since it assumed ill intent. But tiny pull requests like that are rarely helpful since the one reviewing it will need to check what pronouns are used in the rest of the documentation to make sure the style is consistent so they just create busywork for maintainers even though those PRs are almost always done in good faith.
I definitely do not think he was leading by example here. Making assumptions aabout why people do PRs and denying them based on those is a good way to create a toxic community.
> the one reviewing it will need to check what pronouns are used in the rest of the documentation to make sure the style is consistent
Huh? Nothing in a software project will ever be perfect – code or docs — so this doesn't seem like a reasonable expectation. It's always a process of gradual improvement, and that can be true for a change like this too.
It matters how vocal and widespread that toxic portion is. In Rust's case, it's significantly larger and more visible and more toxic than I've seen in, say, the Python or C camps.
> so following that logic all wells would be easily poisoned
All camps are easily poisoned. What's important is how each community deals with the toxicity and whether they consider it acceptable or not. Rust's community has generally accepted this rabid part of it and tacitly accepted their behavior.
Eh, I don't personally consider the Rust Foundation to have anything to do with Rust The Language. I consider "the community" to be everyone who doesn't have official ties to the language. Is this incorrect?
Choosing between Rust or Swift is a false dichotomy.
Switching programming language (or game engine) mid-course is a well known suicidal move.
Who is asking them to use a different programming language? I am not a C++ fan, but it is a lot less risky to stick to it than switching, and this is true for any large projects ran by experts.
C++ is a loaded gun, strapped to your body and aimed at your foot, with infinite bullets automatically firing every second, that requires you to constantly exert 25 lbs of force to tilt the gun and avoid hitting your foot.
Most of the time, you’ll be successful. However, nobody seeing your plight would be shocked if your foot eventually gets blown up. To claim this state of affairs is just fine because you’ve done it for years, pitiable.
Well, there are indeed many ways to shoot yourself with C++, this is why having C++ experts on the team is a good thing. They are supposed to know how to avoid the traps and avoid being lured into the worst parts of C++ and OOP design style.
I have seen very good C++ projects using only the minimal amount of bullshit features, Omar Cornut's Dear Imgui comes to mind as an example.
As Swift beginners, they are less likely to avoid the bad idioms, but this is the kind of thing you only discover late, when the codebase is large enough.
Can you really tell me, that any C++ codebase doesn’t have memory safety bugs?
The last decades have shown that almost every C++ codebase has a bug somewhere, as long as you look hard enough. That’s not a good state of affairs.
C++ is a reactionary language. The programmer assumes they are an expert who can use it safely, there’s just a few exceptions or mistakes here and there and that’s normal.
Using memory safe languages is a programmer knowing they will mistakes, that they aren’t that smart despite their best efforts, and mitigating the opportunity.
can you please substantiate in which points and how right he is? do you have experience with complex object graphs in Rust, direct or indirect experience about the community? thanks!
> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough.
I've experienced this same feedback when I was struggling with Rust. One time when I posted in the Rust subreddit about it seeking help and talking about my struggles, I got the unhelpful response of "I believe in people" as a dismissive response to my struggles. Admittedly this was years ago and I've since moved on from Rust, but the blog post is dated from 2024-04-26, so it appears the issues with the language still remain
It's not specific to Rust at all, I remember hearing the same kind of talks when learning Java because I found OOP confusing.
And in fact most people saying that are right: most of the time people complain about stuff because they haven't internalized how it's suppose to work (as I was).
Don't get me wrong, there are plenty of valid criticism of Rust or Java (and OOP in particular), but at the same time in practice most of the people who complain aren't at the level of understanding and their criticisms aren't good.
Both are true at the same time:
- every programming language has terrible flaws.
- 99.9% of the criticisms you'd see online about a programming language in particular are garbage.
> It's not specific to Rust at all, I remember hearing the same kind of talks when learning Java because I found OOP confusing.
You're right, but that doesn't excuse it. And most languages don't have this as their first bullet point in their code of conduct
>We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
What is the point of a code of conduct if you can't rally the community around the first part of the first bullet point. If people are still experiencing toxicity on the level of other communities that don't have a code of conduct, then it's not working and the leaders of the Rust community should do something about it.
> the leaders of the Rust community should do something about it.
You should read the reaction of the Rust community leaders to the quoted article, and you'll see that they share your opinion that something must be done.
At the same time when you have people in the community saying politely and cheeringly that “you'll get over it when you've internalized the rules” what are you supposed to do as a mod? It obviously doesn't infringe the code of conduct even though it seems to have offended the author of the article.
Also, when what the people get pissed of about a community is “they don't want to admit it doesn't work” it's had to say that the toxicity is “people are still experiencing toxicity on the level of other communities that don't have a code of conduct”, by any means…
The goal of a CoC is to make sure nobody gets bullied or harassed, not that nobody will ever get annoyed by other people. You can't make sure you don't have idiots in your community, all you can do is making everyone behaving in a civil manner, which is already hard enough.
I think the loglog post is great and the community (as I perceived it) basically unanimously agreed that there are sharp corners and lots of room for improvement, especially in ergonomics.
Yep, communication is hard, and it's ... not an easy problem to be a volunteer based project, with a disavowed subreddit where most people get their first contact with the community.
I personally have no experience with Bevy or anything Rust 3D (well or any 3D really except for some tinkering with GLEW 10y ago :D), but the GUI problems are real. Documentation is scarce (no, vomiting types into a HTML page is not documentation, thx).
Andreas Kling @awesomekling · 44m
My general thoughts on Rust:
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
- Really impressive ecosystem
- Toxic community
==============================