I'm honestly glad that Go, unlike C++, does not have features that are useful only for a small subset of programmers. The only 2 cases I've seen where operator overloading is useful are:

1. String concatenation (Go has it) 2. Matrix/vector operations

That's it. Any other use case for operator overloading is dubious at best. It sucks for scientific programmers, but Go is a general purpose language, not a Scientific Programming language.

Complicating parsers, the grammar, readability, all those things, just to please your sub-group -> no thanks.

> Complicating parsers, the grammar, readability

Operator overloading has absolutely no effect on the parser or grammar.

It may harm readability but that's more a question of naming. An operator is just a name. If you use that name to refer to something unexpected, you'll harm readability. If you use it for something intuitive, you'll improve it.

I don't disagree with you. I'm not suggesting that Go designers made the wrong decision with the goals they had. I am jealous that it's less useful to me though.

forgive my ignorance, why is operator overloading particularly useful in scientific computing?

Because it lets your math code look more like math and less like code.

    v := Vector{}
    v2 := Vector{}

to add the two vectors, currently you have to do something like

    result := v.Add(v2)

rather than the nicer

    result := v + v2

In the small scale, it doesn't seem like a big deal. In a large and complicated scientific program, it can make the code a lot harder to read.

Note: I think it is good that Go does not have operator overloading, though I think it's a shame that means it's not as good for scientific & math programming.

So your code can still look like math when the operands are complex types.

Is it really a "requirement," though? It sounds like it makes it easier to look at formulas as you would, say, on paper, but you can still build the same things as methods & functions.

It's not a "requirement" in the strict sense of the word, but I think it's useful enough to prevent the use of Go in science. Java has essentially suffered the same fate in science.

Could you please give an example of code using one style vs the other that showcases why someone would turn down a language for it?

Say I had an array of masses and their velocities and I wanted to calculate the kinetic energy of each mass using the equation:

    E = 1/2 mv^2

With operator overloading:

    E = 0.5 * (m * v)**2

Without:

    E = (m.mult(v)).pow(2).times(0.5)

The operator overloaded example is Python (numpy) - the non-overloaded one is something I made up, but it's basically what it would need to look like.

I think the first example is much closer to the maths.

This is not some contrived example, if you have raw data and you're using mathematical equations to work out relationships you do this kind of thing all the time.

Look at this http://stackoverflow.com/questions/11270547/go-big-int-facto... and compare how the function looks with int and with big.Int. Interestingly, big.Int has a method MulRange, which does exactly what the function would otherwise do, but this won't be the case the majority of the time. Given the extra tedium involved, someone working heavily with vectors, matrices, big numbers, etc., would certainly care about operator overloading.

I am not a scientific programmer, but I'm going to attempt to provide an example anyway until someone else does one better.

I think there are certain mathematical operations that operate over what would be implemented as complex objects, so it is convenient to continue using these agreed upon symbols to implement your work.

  // addition and multiplication of native integers
  1 + 3 * 4

  // add and mult of math objects
  matrixA + matrixB * matrixC

  // here the math is slightly occluded
  add(matrixA, multiply(matrixB, matrixC))

There are proposals out there for adding multi-dimensional matrices to the language. I do like the recent proposal for 2-D matrices I read about. I think that would be a better for the language overall, than adding operator overloading.

Just as a clarification, the proposals are to add multi-dimensional slices (dynamically sized arrays). This statement is splitting hairs, but a Matrix is a container for numeric types that can do things like multiply and have a cholesky decomposition. A multi-dimensional slice is just a container for whatever you want. Such a container is very useful for matrices, but a package would still have to turn a multi-dimensional slice into a Matrix in order to add methods like Add.

I'm very curious why you say operator overloading is a requirement. It's certainly nice to look at code with operator overloading when you're trying to understand a problem (or maybe it's a curse when you're trying to understand what a block of code actually does!), but it's the plainest case of syntactic sugar I can think of in language design. What are you getting from operator overloading that you can't get from chaining methods?

If you work with vectors and matrices and do a lot of computations, it is very convenient to be able to express, thanks to operator overloading, the formula you have on paper into code with nearly the same syntax. This is one area where, for example, FORTRAN still shines. You can can really TRANslate your FORmula into code easily.

In the case of FORTRAN it is because the vector and matrices are recognized types, in other language, they are not built-in types but the convenience is added thanks to operator overloading.

Yes, exactly. The same could be said for computer graphics, where we traffic in vectors and matricies all day. I want a language in which those are base types, will all of the proper operators already defined, so I don't need operator overloading. Yes, I could write in Fortran, but something a little more modern would be nice.

Fortran is coming up to speed pretty quickly. The 2003 and 2008 updates to it are pretty nice. In fact, I'm in the process of porting the nanomsg sockets library over to it. You can even use GTK3 and Glade to make GUIs for it now, too. I do a lot of matrix calculations, so Fortran is absolutely invaluable.

A simple preprocessor for transforming custom infix operators to method calls might do the trick here. Go comes with good libraries to make this, you wouldn't have to invent a new Go parser. There are other preprocessors that you can look at for inspiration.

That would produce a custom language not understood by other Go users and destroy much of the benefit of the compiler reporting errors straightforwardly.

Sounds very much like the incumbent popular language supporting operator overloading!