> I guess Go can't do type inference on the function types though?
It can't, and there are no generics which is why the input has to be cast back to a Student* in every function. Also why the Sum implementation and the min, max and order (sort) situations are absolutely gross.
This is one of two main complaints I have with Go[0], which I've used professionally for the last six months or so. There have been several times when I've thought "if only I had generics..."
Instead I either have to use interfaces and casts (run-time when I would prefer compile-time) or write separate functions for each type (I wrote a Cartesian product library that abstracts the math involved to indexes and lengths, then requires a simple type-specific wrapper simply because of this silly language gap).
Despite that, I still really love Go.
[0] The other being that 1.2 randomly segfaults on my code base during compilation whereas 1.1.2 works fine. For this reason I haven't yet been able to upgrade until I determine the cause.
I wrote Go for about 6-8 months and having to do so much stuff run-time when I wanted the guarantees of compile-time started grating on me along with generics and the type system being stringly typed.
I found Haskell shortly thereafter and that is where I currently stay ;)
Well, I wouldn't say I have to do "so much" run-time, only when I'd like to write a generic library, and in that case I make a judgment call whether I want to write type-specific functions or type casts. When I absolutely have to, I just apply C polymorphism techniques.
