MicroSCOPE VS go

To be fair to those projects, the type was introduced only three years ago:

https://github.com/golang/go/pull/49359/files

Before that, doing a string compare was basically the only way to detect that specific error. That was definitely an omission on the part of the original authors of the stdlib code; I don't it should be classified as "Hyrum's Law".

git clone https://github.com/golang/go OR git clone https://go.googlesource.com/go

I install go.

The difference between types.Implements and types.Satisfies is mainly a history reason, a tradeoff between keeping backward compatibility and theory perfection.

It is pity that Go didn't support the "comparable" interface from the beginning. If it has been supported since Go 1.0, then this tradeoff can be avoided.

There are more limitations in current Go custom generics, much of them could be removed when this proposal (https://github.com/golang/go/issues/70128) is done.

I recommend people to read Go Generics 101 (https://go101.org/generics/101.html, author here) for a thoroughly understanding the status quo of Go custom generics.

Tried to contribute to a Go project a few months ago and got bitten by https://github.com/golang/go/issues/67296 due to questionable doc quality. I was pretty disappointed to find that natural sort isn't builtin since Go was the Unicode language in my mind (Go runes, made by some Plan 9 thus UTF-8 creators).

Go has a lot of good points, but I immediately felt "dirty" when using it. Like that time when I tried to wrap a closure variable over itself ("my_closure = new closure calling my_closure") and needed to use a temporary variable because closure captures are always by reference: if you want to build abstractions, you got to think them better; as it stands, this is the worst of both worlds I know (C++ makes capture type explicit and customizable, Common Lisp was designed by wizards who knew what to do cf https://www.tfeb.org/fragments/2023/02/22/how-to-understand-...).