I'd argue that the reason this is so bad in other languages is because of horrible default implementations. Look at tostring in java, getting a somewhat printable object would be easy if the default implementation would use reflection or sth to print the object, but instead it prints hash gibberish no one cares about.

Now explain PartialEq, and why it's mandatory.

Fun story from before Rust was getting popular (years ago). So, I did a performance comparison to determine what language we should write our rules engine in. I compared Go, Rust, Node, and some others not worth mentioning.

At the time, I had experience with all but Rust.

Even knowing nothing, and working from scratch, the Rust POC was significantly faster. Just way, way, better.

That being said, I still chose Go due to productivity based on the language knowledge of the team to ease the transition (Go was closer to what they knew already), and while it was good for them to learn Go, I look back on it and realize Rust would have been a great opportunity to invest in their careers and have them learn it instead.

A hindsight is 20/20 experience for me.

I'm much more impressed by the fact that a type can implement PartialEq and not Eq. Now that's nice design!

In Go "==" operator works for everything by default, I like it more:

type A struct {
	Name string
	Quality int
}
func main() {
	var x A
	var y A
	fmt.Printf("%v", x == y)
}

(if all you want is to compare all corresponding fields which you usually want)

The problem with rust, I always find is that when you're from the previous coding generation like myself. Where I grew up on 8 bit machines with basic and assembly language that you could actually use moving into OO languages.. I find that with rust, I'm always trying to shove a round block in a square hole.

When I look at other projects done originally in rust, I think they're using a different design paradigm.

Not to say, what I make doesn't work and isn't still fast and mostly efficient (mostly...). But one example is, because I'm used to working with references and shoving them in different storage. Everything ends up surrounded by Rc<xxx> or Rc<RefCell<xxx>> and accessed with blah.as_ptr().borrow().x etc.

Nothing wrong with that, but the code (to me at least) feels messy in comparison to say C# which is where I do most of my day job work these days. But since I see often that things are done very different in rust projects I see online, I feel like to really get on with the language I need a design paradigm shift somewhere.

I do still persist with rust because I think it's way more portable than other languages. By that I mean it will make executable files for linux and windows with the same code that really only needs the standard libraries installed on the machine. So when I think of writing a project I want to work on multi platforms, I'm generally looking at rust first these days.

I just realised this is programmerhumor. Sorry, not a very funny comment. Unless you're a rust developer and laughing at my plight of trying to make rust work for me.

I do appreciate how newer C++ standards have made these kinds of things a lot easier too.

Define all comparison operators with just one one line using C++20

auto operator<=>(const ClassName&) const = default;

But then you realise that the types of 10 constituent fields don't implement Eq, PartialEq...

Haskell: deriving Eq

Is that because it's that simple, or just that the boilerplate is pre-written in the standard library (or whatever it's called in rust)?

I mean, if your IDE does it for you, is it really that much better that it's shorter?

I've only had to implement equality in C# but that didn't seem that hard of a problem. you just expand the operator = function