3 ms·

I can't speak for @ak217, but for me Go hits a bad spot on "expressibility". Some of the nuances of static typing are mitigated a bit with features, yes, like t

I can't speak for @ak217, but for me Go hits a bad spot on "expressibility". Some of the nuances of static typing are mitigated a bit with features, yes, like the type inference on local variables, or the automatic interface detection (i.e. no explicit "type X implements Y"). But overall, i think the chosen type system is lacking on expressibility. Having no parametric polymorphism in a static language is a deal breaker for me at least. No way of doing type-safe parametric container types for example.

strmpnk 14y ago
It's a fair complaint. Duplicating code just for the sake of type specialization is annoying and interface{} has it's costs as well as dangers. However, the built-in arrays, slices, and maps (which are parametrically polymorphic) seem to have covered all the cases where I need parametric types so far. Maybe I'm just lucky or haven't written enough lines of Go but it seems like an 80/20 sort of feature in the presence of the built-in maps.
Evbn 14y ago
You can use reflection to get parametricity. Python doesn't have type safe anything, so Go bests Python on that front.
- rryan 14y ago
  If I'm going to be burdened by a static type system, then I expect it to do certain things for me in return. One of those things that I take as a given is that a static type system can check that my basic use of types in my program are safe. Not being able to type-check something as simple as a container lookup is a show-stopper for me because using containers is a huge part of day-to-day programming. Static typing without parametric polymorphism is extremely retrograde -- like Java in the 90's. I've read rsc's essays on adding parametric polymorphism to Go -- I'm not saying it's a "duh -- just add parametric polymorphism". I'm well aware of the issues -- I'm just saying that Go looks great except for this glaring exception.

strmpnk 14y ago

It's a fair complaint. Duplicating code just for the sake of type specialization is annoying and interface{} has it's costs as well as dangers. However, the built-in arrays, slices, and maps (which are parametrically polymorphic) seem to have covered all the cases where I need parametric types so far. Maybe I'm just lucky or haven't written enough lines of Go but it seems like an 80/20 sort of feature in the presence of the built-in maps.

Evbn 14y ago

You can use reflection to get parametricity. Python doesn't have type safe anything, so Go bests Python on that front.

rryan 14y ago
If I'm going to be burdened by a static type system, then I expect it to do certain things for me in return. One of those things that I take as a given is that a static type system can check that my basic use of types in my program are safe. Not being able to type-check something as simple as a container lookup is a show-stopper for me because using containers is a huge part of day-to-day programming. Static typing without parametric polymorphism is extremely retrograde -- like Java in the 90's. I've read rsc's essays on adding parametric polymorphism to Go -- I'm not saying it's a "duh -- just add parametric polymorphism". I'm well aware of the issues -- I'm just saying that Go looks great except for this glaring exception.