Huh, as a non-go programmer, I was pretty shocked to see it doesn't have operator overloading. How have experiences with that been? Seems like a big omission but it is a pretty well regarded language, so I guess they must have thought this out.
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.
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 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...
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.
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.
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++.
