Hacker News Reader

Comment by campbel | Hacker News Reader

I'm really not a fan of small qol features like this. I think it really hurts readability for the general audience. The function itself is minimal overhead and is clearer to the reader.

View on HN

That's true, we should get rid of operators for primitives too.

Operators for primitive types are fine, they are well defined by the language and consistent across programs. Operator overloading is going to change behavior between programs which puts extra cognitive load on the reader.

That said, Go sticks to the most basic operator implementation (strings, numbers etc...). Go doesn't support `+` on slices for instance.

In better languages they don't exist except as sugar, they're functions themselves.

The world seems like it's moving to ML. That needs matrices, complex numbers, autodiff, different fixed/floating point types. All four of these need operator overloading.

Could you explain _why_ they need overloads and functions don't work? That does not immediately follow for me.

Autodiff requires interpreting the same piece of code using "dual numbers" that would normally expect "real numbers". This needs operator overloading combined with generics.

Your last sentence seems fishy to me. Are you suggesting that support for C++ like operator overloading is a necessary condition for, say, autodiff? I thought Go is a Turing complete language.

Operator overloading is about syntax and type safety. Brainfuck is Turing complete.

I agree it is about syntax. But how is it about type safety?

You might want the same piece of code to work correctly under different numerical types. Answer: Op overloading + generics.

E.g. Dual numbers for autodiff; 2x2 matrices of quaternions for texture mapping; matrices of differing floating point types for machine learning. Why should I implement the same matrix operations a million times over?

Reply on news.ycombinator.com