Rust, sloppiness, and gatekeeping

Perhaps that is the case if the developer's alternative language is a mostly memory safe language like C# or Java (although they are worse off in those languages with regard to data races). If their alternative is C or C++, then abusing unsafe is no worse than what they'd end up with anyway. At least with Rust everyone else will be able to audit and/or avoid their code easier.

It depend on perspective.

As someone who came from Python, my perspective is "You expect me to take responsibility for choosing the right dependencies when I came to Rust to get more compile-time guarantees and know just enough C and C++ to know I'm not qualified to audit memory-unsafe code? OK, with a handful of foundational exceptions, I'll choose a subprocess from the side of the APT repositories that Ubuntu borrows from Debian over a crate containing unsafe every time, because I know that's the responsible thing to do in my case".

I personally have "fear" to use the word "unsafe" in my code. I don't feel smart enough to use "unsafe". I imagine if I worked in a shop that did something like coding my boss would grep for the word and question me for using it. Nobody wants to be questioned by the boss, so it is kind of a deterrent?

1 Like

Whether Rust is or isn't for sloppy thinkers is not relevant. I could argue the other way: Rust is the best language for lazy/sloppy thinkers! In languages like C upholding of safety invariants is all programmer's responsibility, so programmers have to be diligent and vigilant. OTOH with Rust, programmers can afford to let their guard down, lazily write sloppy code, and rely on the compiler to ensure it's safe.

But either way, classifying programmers like that is a version of the "Real Programmer" rhetoric, which does put people down and puts blame on the programmer, rather than the language (sometimes that's true, but generalizations of such statements are unhelpful).



As I said "Rust is exactly the language that sloppy thinkers need.". And, we are all sloppy thinkers at some time. Which must be true else programs would never have bugs, especially when written by the best of programmers. But they do have bugs.


As a Rust programmer who's been using Rust for a few years now, I can say, without a doubt -- no, indubitably -- that Rust has made me a far better programmer. I can read C code and think about whether its safe in the context of what I know about what the Rust compiler might say if it looked at the code I was reading. The ironic thing about my transition to Rust is that its actually harder for me to write C/C++ properly now because I feel like its almost... Alien if you will. When I write the code, I think a lot about its safety and correctness and I'm always looking for ways I can make it better. If there is any language that shows you the major flaws in languages like C/C++, it is undoubtedly Rust. Sometimes I go back and look at old code and I wonder "What the hell was I thinking?".
So yes, I can definitely see how Rust would melt the brain of a programmer coming from C/C++ when they don't know the underlying concepts behind it all that well or are used to programming in C/C++. Rust forces you to be a better programmer, without exception. It rains on your parade and can definitely make someone look stupid/arrogant (you know, that "I'll just write this code and it'll work on the first try, they compile it and Rust wines because they did something wrong" kind of mindset that we all get once and a while).
Hope I didn't go off-topic or derail this one.


I still do this with pretty much everything I've ever written...


Not just sloppy thinkers. I need Rust because I'm a sleepy thinker.


Yes, and far too hot. My brain does not work at elevated temperatures. But must keep going, must keep going... deadline coming... must keep going...

Rust compiler - BAM! another borrow checker error.

OK, rustc, you win. It really is time for me to take time out. Wait for the cool of night. If that ever comes.

1 Like

I think we have different definitions of "lazy/sloppy thinker"

Consider someone who regularly formalizes math proofs in Lean / Coq. Can they be a "lazy/sloppy thinker"?

In my definition, no. Anyone that daily battles Lean / Coq to submission is thinking very rigorously and clearly.

If I understand your / @ZiCog's definitions correctly, under your definition, yes -- in fact Lean / Coq is great for lazy/sloppy thinkers because one can be lazy/sloppy, and the compiler will catch all the errors.

If we replace Lean/Coq with rustc, this seems to be the two sides of the argument.

I don't think either of us will convince the other of the "correct" definition, but it seems our disagreement stems from having different axioms / definitions.

It's not about the definition of what a sloppy thinker is (I unnecessarily argued about this in my previous comment).

It's about promoting a generalization that divides programmers into those who are and aren't good enough for a programming language.

Rust doesn't want to tell people they aren't good enough for it. It's fine that Rust isn't appropriate for every use case. It's fine that Rust isn't interesting or worth learning for everyone. But it's not fair to label people with derogative terms when they haven't managed to please the borrow checker.

Even if you go by a definition that makes "sloppy thinker won't pass the borrow checker" 100% true, it's still not a great thing to say. People often misunderstand negation of p=>q statements, and could think "I can't make the borrow checker happy, therefore I'm a sloppy thinker", and we don't want to people to think that. People more often get stuck because Rust is different from other languages, and has a steeper learning curve. Not everyone invests enough energy into learning it, and there are many rational reasons for it that aren't caused by someone's way of thinking.


I think we are on the same page. Perhaps looking at it from a different perspective.

I take my understanding of "sloppy thinking" from the definitions of "sloppy":

messy or lacking care or attention

careless and unsystematic; excessively casual.

As in: "careless", "slapdash", "slipshod", "lackadaisical", "disorganized" etc.

The sloppy thinker does not ensure his assumptions are true, does not take the trouble to think things through to their ultimate conclusion.

Rust of course won't let one get away with any of that when it comes down to memory use safety.

1 Like

Agreed. That's why, when I'm not engaging in self-deprecating humour, I talk about Rust helping when you're having a bad day, rather than being ideal for a type of person.

Everyone has bad days.

The problem with debates over word choice in generalized put-downs is that it doesn't matter what you think or thought the word meant. What matters is what the reader thinks -- every reader.


I'm not sure there was any put-down intended. At least that is my assumption.

Which is clearly impossible. We cannot know how every reader will interpret our writings.

"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
"The question is," said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty, "which is to be master—that's all."

1 Like

Every compiler divides programmers into: (1) those sufficiently competent to write code the compiler (eventually) accepts and (2) those who write code the compiler rejects. 'Generalizations' are conditional expectations.
Ex: typical C programmer knows more about x86 assembly than typical JS programmer. typical JS programmer knows more about CSS than typical C programmer.

I suspect the core issue is that we have very different implicit motivations.

My primary interest is, with limited time/data and in the fewest number of queries, figuring out: is programmer P0 capable of solving task Foo1? This implies being (1) divisive (those with the skills to solve Foo1 vs those who do not), (2) making decisions others would find offensive (i.e. P2 is not qualified), and (3) primarily interested in the quality of the produced code.

If I am reading your motivations correctly, your primary concern is: helping new Rust programmers learn Rust without any unnecessary hurdles. From that perspective, I can see how my heuristics/generalizations for judging competence looks divisive / abrasive / elitist.

Given the context (this is a language help forum, not a job board), I can see why you would find my views concerning.

1 Like

@ZiCog : I think you caught a stray bullet meant for me. :slight_smile:

I've done this for a particular project, though not because of compiler errors, but rather because of a feature rust lacks (in this case, the lack of a stable abi). This could arguably be read to incldue that kind of case, and I'm not sure that's a good thing or is what is intended. Reguardless, though, that is a reasonable interpretation of that statement.

For the record, I am not offended by this statement, nor do I choose to interpret it that way, I'm just noting that someone in a similar situation could interpret it that way and could be offended.

First off I agree that this line of argumentation is a form of gatekeeping. Rust is awesome because it enables a much more diverse group of people to do low level programming. It's about bringing people in, not keeping them out. The undertone of some comments here seem to be classifying certain kinds of people as undesirable to the Rust community. It declares a gate and wants certain people to stay out.

Additionally, seeing how many people in the community seem to believe that a = b can't trigger allocations, or that Rust 1.0 code is guaranteed to still run, I would argue that in-depth awareness doesn't really seem to be a necessity to be part of the community. I wish there was more awareness. My solution is to keep talking about these kinds of things even if there's going to be downvotes. I'd rather be downvoted than keep or kick people out.

And as a final note, we already have enough tribalism. In the Rust community and the software community in general. I don't think it's a good thing to elevate that to some kind of virtue.


You are attacking a strawman.

I never tried to gatekeep who has a right to learn Rust.
I never tried to gatekeep who is part of the Rust community.


I have an absolute right to gatekeep "who I choose to work with / not work with"

I suspect you gatekeep too. I suspect you are "divisive" in that you divide programmers into those that you enjoy working with and those that you do not enjoy working with. Some people might even view you as "offensive" or "putdown" for putting them into the second category.