For those not in the know, a redundant method (/=) is removed from the Eq class and added as a regular function, and, apparently, this is making a few people very angry. (Not sure why though)
On the one hand, this is a change whose software engineering benefit is very small. (There is a small performance advantage, but it's not significant.) It has a large aesthetic benefit, though, in that it makes the standard library have one less ugly wart. But that wart wasn't really doing anything except being ugly. Some community members have a point of view that "ugly" shouldn't matter, and that in particular, the bar for breaking changes should be very high, and far higher than wart removal.
On the other hand, this particular change should affect extremely little actual code, because defining (/=) explicitly is dumb. When it does affect code, the solution is just to delete the lines of code that are doing the dumb thing. They don't even need to be replaced, because the only reasonable behavior is already provided by the default. Just deleting the dumb code is enough.
On the OTHER other hand, even a small amount of code change can add up to a lot of dependency management work. If just one library somewhere at the leaf of a dependency tree needs it's explicit (/=) deleted, then version bounds need to be added for all upstream bodies of code to ensure that they don't try to build against the old now-broken. Changing all those version bounds across perhaps dozens of packages is far, far more work than just deleting those few lines of code. You can look at this as a broken process, but I don't think anyone has a great answer to dependency management.
So I think it's in the end kind of a coin flip between (a) it's infuriating to some people not that this specific change is being made, but that it indicates the community values aesthetics above backward compatibility, and the absence of almost any practical software engineering benefit makes this a compelling test case upon which to direct their fury, and (b) despite the tiny amount of actual code change, it's quite possible it could lead to a non-trivial amount of coordination work between libraries, and THAT is a real (and not very fun) job.
The way this works is that when you implement the `Eq` typeclass for a type, you can provide more specific implementations. A minimal complete implementation is to implement either == or /= for your type, and the other definition will apply.
The way this breaks existing code (iiuc) is that as a top-level function, if you have imported the `Eq` type class but haven't imported the `Prelude` module implicitly (on by default but can be turned off), you will not have `/=` in scope anymore.
I think people are upset by this less because of how hard it would be to fix, but more because of how it acts as a sort of signaling change ("they're willing to break my code for this, which I didn't want, but not for X which I did"). The most common value of X I've seen is removing or reworking the partial functions in the Prelude (e.g., head / tail on `[a]` raising an exception instead of returning `Maybe a`).
Right. With the current situation you could define a custom /= for every type. In the new situation /= is a regular function which is defined as `a /= b = not (a == b)` and you wouldn't be able to redefine it.
