> Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word.

Isn't this just true of any word with increased specificity? Why call it a square when we already have rectangle?

I'm not really seeing how understanding method vs. function is "highly technical". At least, not more technical than, I don't know, writing Rust code in the first place?

It’s just not a particularly useful distinction IMO. I have worked in C++, C#, Ruby, and Rust over the past 25 years of programming and outside of academic contexts I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method.

In academic circles, there’s some meaningful distinctions to be made. In software engineering I’ve yet to find a place where having a very specific name mattered or reduced communication burden.

This might be your experiences, but I've never worked with people who called member functions methods in C++. I've seen C# programmers who had never worked with C++ call them that, but in the C++ teams I can't recall an instance of that, even for multi lingual engineers

Though I do tend to work with teams where the average age is higher than the industry average, that might be warping my anecdotal experiences

I have had situations where the distinction matters, and they aren't academic either, but in API design, especially for libraries

I’ve had a similar experience, but if someone called a method a function or vice versa, it’s never been unclear what they meant. And it’s never been something that people would have felt the need to correct someone on.

I am aware of the distinction and I (probably?) instinctively use the two terms “correctly” the majority of the time. But if I just picked one or the other and used that word 100% of the time I would wager there would be zero confusion, except amongst pedants.

For what it’s worth, I say this as an avowed pedant.

> I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method

Because _you_ haven’t means the entire industry is wrong?

I’m not saying the industry is wrong. The two words have clear and distinct meaning.

My point is only that fretting over the distinction between the words serves nearly zero utility in day to day software engineering. It’s like “less than” vs. “fewer”. Each has a correct use, but nobody is confused when you use the wrong one. Many confuse the two, to the point that it’s becoming less and less wrong to use one when the other should be used. “Method” and “function” are similar.

In twenty years, nobody is going to care that they once had a distinctive purpose because that distinction serves little utility.

“People will know what I mean, so why bother being correct or specific” is a flimsy argument, to me, as to why a person shouldn’t care about using correct and precise language. Nor does it really challenge the need for correct and precise language in the first place.

Small children say things incorrectly and we still understand them. Should we all talk like that?

Language is fluid and changes over time. Pedantically clinging to distinctions that no longer serve useful purposes doesn’t stop this from happening.

If a clear separation in meaning between the two words was useful, their distinct use would become more closely adhered to over time. If not, people will start to blend and confuse the two. Of those options, the latter has happened and will likely continue happening with or without your objections.

That this has happened is pretty clear evidence that the distinction hasn’t been worth maintaining.

> Small children say things incorrectly and we still understand them. Should we all talk like that?

Fully grown, articulate adults say things “incorrectly” all the time and nobody bats an eye. The sentence “Hey, where you going?” is missing an entire verb and every one of us has said and heard that sentence (or one like it) hundreds of times without anyone noticing or caring.

Yes, exactly. Language is fluid and the value of preciseness depends entirely on context. As in, when discussing language design (like we’re doing in this blog post and these comments), method vs function is important. Because of the context.

So, when you’re talking to your coworkers about…whatever… the context probably makes method vs function insignificant. Unless you work in language design, in which case your take is just pretty blatantly awful.

I write Java daily. I find a lot of value in marking functions as static to make clear that they are not methods. There is a lot less cognitive overhead wondering if they only operate on their arguments or if they drag in their closure and the rest of the universe.

Rust-specific nomenclature aside, I think it's useful in technical discussions to distinguish between (object) methods, class methods, and functions if your working language supports any combination of the three.

The word "method" is baked into the official Rust docs[0], and while I personally find the definition in the docs to be satisfying, I don't think the author's argument for narrowing that definition down is unreasonable or (more importantly) unworthy of discussion.

    [0] https://doc.rust-lang.org/rust-by-example/fn/methods.html