The article is great. The bigger picture, of course, is that it’s always “pick your poison”.

On one hand, say, I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work).

On the other hand, I can appreciate the choice not to do it at all because half of the ecosystem will do it, and another half won’t. Also, it would require implementing function overloading, and it is a can of worms.

Or generics and rich type systems, which all come with their own tradeoffs. I hear that Rust cajoles you into tinkering with the type system, and wach tweak requires refactoring of more codebase than anyone would like (don’t take my word for it, it’s just what I heard from a few different sources). I know that Nim is so expressive that it can be annoyingly trivial to be too clever and run into a valid edge case that will make the compiler barf and die. Go sidesteps the issue by not wading into that territory, and that may be perfectly okay, albeit verbose.

It’s always picking your poison, so I guess check your tolerances and allergies so it doesn’t kill you before you get the job done…

> I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work).

Is this different from other styles of operator overloading? Why does it matter whether, when I want to overload the + sign, I need to define a function called `__add__` or `operator+`?