I can see the argument for operator overloading being necessary, but I don't understand the argument for generics. There's basically no time I've wanted generics coding Go, except a couple times with float64 vs []float64. I also see the need for float32 vs. float64, but that's a very small use case for generics in terms of scope (we can and do autogenerate float32 code).

There's a couple of cases with float64 vs. complex128 matrices, but I have been annoyed with those silent changes in Matlab where the answer is wrong but the code continues anyway.

For numerical computing, rather than dynamic multiple dispatch, what is actually desirable is a type system that can figure out statically the kinds of result produced by multiplying different kinds of arguments.

"So I guess my question is: why do you need generics when you have interfaces? These other (admittedly dynamically typed) languages make do without."

Going backwards, as you allude to, dynamic languages fulfill the use cases for generics, as long as you don't care about type safety, which is a thing that is true for the whole language anyhow so it's not much to give up.

For Go, the main problem is that when you're trying to be mathematical, with interfaces you get the worst of both the static and the dynamic worlds. You might like to define an interface that lets you add two vectors, right?

    type Vector interface {
        Components() []float64
    }


    type Add interface {
        Add(Vector) Vector
    }

which might let you implement an Add method on something that is a Vector as well, but you don't get a satisfactory result from either perspective. From the static perspective you can not, using interfaces, guarantee that someone doesn't add a Vector3 to a Vector2, meaning you must either panic at run time or have Add potentially return an error (that will generally not be necessary to check if used correctly, which is not a pleasant error to work with). From the dynamic perspective, you have to remember that what comes out the other end of that operation is always an Add interface value, not a concrete type, so if you have a Vector2 and .Add(Vector2) to it, you don't get a concrete Vector2, you get a value of type "interface Add", which you have to manually cast back to a Vector2 if you want to do anything more than just keep adding to it.

You can make Vector2 have a distinct .Add(Vector2) method which does return a Vector2, but then if you also have a "func (v Vector3) Add(Vector3) Vector3" function, there is no way to declare an interface that both of those methods can meet, so you can not write any dimensionally-oblivious code that uses generic vector adding.

In "normal software engineering", Go's interface limitations are often not so bad, certainly not as bad as is often portrayed on HN. However, when you try to create a strongly-type numeric system (and you want it to be strongly-typed because that's also how you get good performance), Go's interface mechanism is basically worthless.

> But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon.

that's true. that is... until a (real) Go interpreter shows up. something that's bound to happen when Go will be used for (data) exploratory work.

Relying on a JIT to get good performance is arguably a bad thing anyway, since JIT compilation makes performance harder to predict. Of course, in the end you need to measure what you have, but you should also be able to make educated guesses about performance when you don't have something to measure, e.g., when you need to select between several alternative designs, and implementing all of them would be prohibitively expensive.