$ irb2.4.1 :001 > ({k: 1} === {k: 1})

=> true

I don't get it. Why would you not want this? And when you're used to it working, how could missing so common and logical not be maddening? When does the maddening kick in... before or after I have to install lodash for comparing objects?

Are you busting me on semantics? Do I literally have to check into a mental health care facility after not being able to natively compare simple ES objects to satisfy you?

I guess it's not maddening to me because I was used to this from C. Two pointers which resolve to the same value and type will still not be equal in an equality expression if they reference different addresses. But to me it's good that {k: 1} !== {k: 1}, because if this evaluated to true I would have no way of determining an object's true identity, which is often more relevant than the value it contains.

You make a (several) good points. I primarily work in Ruby and it's true that comparing a potentially complex object like a hash based on whether it serializes identically essentially means that you're comparing by value instead of reference. Depending on what you're doing, that's either really convenient or a nightmare. Ruby seems well adjusted to tasks where accessing a hash as a value is a feature and not a bug.

And for those times where you're interested in comparing instances of a hash, every instance of an object has an object_id getter:

a = {k: 1}

b = {k: 1}

a == b # true

a.object_id == b.object_id # false

Of course, this is a lot of typing, so Matz also gave us:

a.equal? b # false

Ultimately, this is what I love about the diversity of a pluralist language ecosystem. The polyglots will always win.