It's cute for trivial cases like algebra libraries, but very ripe for abuse (std::cout) and hard to get right for scenarios where it’s two different types being operated on, especially if a) the leftmost one is a built-in or b) various combinations of casts could get you to a supported operator.

Rust obviously does do operator overloading, but it addresses (a) mostly through culture, and (b) by insisting on explicit casts everywhere.

> It's cute for trivial cases like algebra libraries

I don't understand this wording. Algebra libraries are nontrivial to implement, as the algorithms that operate on such structures can be exceedingly complex, and there are many types of algebra relevant to computer programming. Linear algebra (and its big brother, tensor algebra), boolean algebras, polynomials...

This is the example I had in the back of my head. Like ok I'll write my code in C or Fortran and dutifully provide all 13 arguments to BLAS because I'm a dummy but I thought people used languages like Go to avoid this sort of thing.

I get that under the hood, a library like eigen has loads of tricks and optimizations to make vector and matrix operations maximally efficient on modern CPUs.

But the comment was specifically about the interface to those operations, that it's convenient and non-harmful ("cute") to have an infix operator just work, because no one would expect that multiplying vectors is going to secretly be a function call that could block or throw or have other unknown side effects the way something like using "stream insertion" on a logger object might. Or have an uncertain effect, like defining operator+ for just one of the multiple possible schemes by which two dicts may be combined.

I don’t like operator overloading much. I think it hides a lot of what’s happening behind the scenes. It’s good syntactic sugar but wouldn’t be a deal breaker for me.

I love python. My personal complaints about it - speed, gil and static typing. Other than that I love using it.

It’s hard to design good operator overloading. In c++ it’s difficult to do correctly to the point of being considered an antipattern in many shops

C++ making bad choices more or less universally impugns on operator overloading no more than on anything else.

It's all about culture. I learned that operator overloading is evil when I worked in C++. Then I worked in python and it's actually fine. Python has much more powerful overloading capabilities (you can overload a LOT more), and yet it's not a total mess like in C++.

I think the only time I used operator overloading was when I was a junior C++ programming trying to be clever - maybe 15 years ago.

Operator overloading is more or less banned in most style guides unless you're working with well known "math" types. And for good reason. I'd love anyone to tell me what the (^@?!) operator in Haskell's popular lens library does.

It's just... not a good feature for the most part.

The few times I've dealt with code that does some (even just very basic) algebraic manipulation, I found the lack of operator overloading to be _really_ awkward (look no further the math/big library). For this reason there are many types of mathematical code that I would never consider writing in Go. But outside of those domains, I haven't really missed operator overloads at all.

Well, I guess the lack of an overload for <, >, and == is somewhat annoying. But I don't think those as are essential as arithmetic overloads are for mathematical code.