Rust, sloppiness, and gatekeeping

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.

2 Likes

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.

4 Likes

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.

3 Likes

You also wrote this:

You're using words like "thinking rigorously", "lazzy/sloppy thinking", "competency" and so on. In the beginning you basically said Rust has a higher level of rigorous thinkers.

Sure, I'm trying to "gatekeep" out the idea that Rust developers are inherently smarter or more competent. But I'd still classify the thought process of enjoying working more with some than others differently than trying to establish some form of superiority.

Are Ada developers that dislike Rust less competent as a group because they think what Rust provides isn't worth it, or have some other reason to avoid it?

2 Likes

This is a tautology.

This is not the same as gate keeping. Gate keeping learning Rust (which I strongly oppose) would be something like this:

  1. You submit an application for "may I please learn Rust?" to FooBar
  2. If FooBar stamps 'accept', you get access to rustc / books / forum.
  3. If FooBar stamps 'reject', you do not get access to rustc / books / forum.

I suspect personal values, not external gatekeeping, is the primary reason people fail to learn Rust.

There is a certain "cost" to writing code that passes rustc.
There is a certain benefit to writing code that passes rustc.

Those who believe cost > benefit quit; those who believe benefit > cost endure.

This to me is a very useful signal about what this particular programmer values.

Every hiring manager ends up labeling candidates as "qualified" vs "unqualified". Do you view them all as guilty of "trying to establish some form of superiority" ?

I do not know Ada but heard great things about it. I will concede this:

  • Neither Euclid nor Archimedes ever programmed in Rust. They both think more rigorously than I do.
  • Therefore, I concede that "uses Rust" is not the ultimate judge in thinking rigorously

I hope you will concede "uses Rust" is a very strong signal for thinking rigorously.

1 Like

What has any of this got to do with judging people who have trouble using Rust?

I find the module system very intuitive, others don't. I was comfortable with pre-NLL borrow-checking, but others weren't. I prefer explicit binding modes, others don't. The fact that these things that I value, that make Rust harder to use for others but provide benefits to me, doesn't say anything about the competency or rigor of thought of those that have problems with it. And the fact that people have trouble with the current module system doesn't become something good because I happen to like it the way it is.

If you said instead: "Uses Rust" is a strong signal for the willingness/ability to invest time to learn new things I'd say yes at this point in time. Large parts of the ecosystem are still in a discovery phase under the Rust/ownership model. And the fact that we're still all mostly learning new things one way or other is one of the current unifying characteristics of the Rust community.

It's one of the reasons I think that for example the low level systems people and the high level web people are working really well together and there isn't too much breaking off into isolated different groups.

2 Likes

Let C be the chain of logic you were using to claim that my comments were somehow gate keeping / divisive / offensive / putdown / "trying to establish some form of superiority"

If you applied C to hiring managers that regularly label people as qualified / unqualified, you would also have to conclude that those hiring managers were gate keeping / divisive / offensive / putdown / "trying to establish some form of superiority". (I personally disagree with this conclusion -- I believe those hiring managers are doing nothing wrong).

But the Rust community is not a company? We don't need to make a choice of which people we "let in". My whole point is that we shouldn't.

3 Likes

You mean on the stack or heap? Because a Drop impl that allocates on the heap is pretty... unusual, to say the least (though it definitely can happen).

It should mostly work, as long as you use the 2015 edition and turn off some lints (there were some breaking changes, but they shouldn't affect the vast majority of code).

There is more discussion here.

In general I'd expect it to work, yes. And the Rust project puts a lot of energy into making it as low-effort and as easy to fix as possible in the rare case when it happens. But it's not guaranteed. The expectation that it won't happen ever is incorrect.

1 Like

Previously addressed in:

I still don't understand what companies have to do with this. Requoting your own comments at me doesn't really clarify anything.

3 Likes

If a language filters out lazy/sloppy thinkers, its actually a Red Flag and of concern. This argument about filtering about lazy/sloppy thinkers is a tired argument made since the history of programming for any complex and large language. This is an elitist statement that can be used to hide any PL defects.

5 Likes