3 ms·

I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity an

by exacube 12y ago

I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on language design. For the rest, use any other strongly typed language that has sort form of type-abstraction/generics (which pretty much they all do).

emmelaich 12y ago
It's useful to know Ian's background too; he's the author of the gold linker (http://en.wikipedia.org/wiki/Gold_(linker) http://en.wikipedia.org/wiki/Gold_(linker) so would be intimate with the sort of problems that generics and map and reduce would introduce to the compilation pipeline. To a language user the benefits might be clear but the problems not. To a language implementor the problems will be much clearer.
Rapzid 12y ago
A thousand times this. If somebody were to go through the process of actually trying to implement a generic map function in the current Go they would get a good sense of just what the issues are. Unfortunately you need a good grasp of the type system and this just isn't something most of the commenters on this subject have; the Go community is much more qualified. I've done this and generics are the first road block but after consigning to working around that you run into a lot of Go implementation details around interface{} and type assertion so that what you end up with is actually quite verbose in practise and no more desirable than the alternative.. I decided that for me, for loops aren't so bad. So it does just come back around to generics but people are solving this with code generation, like gen which looks very interesting, and I imagine that is quite acceptable for the time being, for those who really want it.

by exacube 12y ago

emmelaich 12y ago

It's useful to know Ian's background too; he's the author of the gold linker (http://en.wikipedia.org/wiki/Gold_(linker) http://en.wikipedia.org/wiki/Gold_(linker) so would be intimate with the sort of problems that generics and map and reduce would introduce to the compilation pipeline. To a language user the benefits might be clear but the problems not. To a language implementor the problems will be much clearer.

Rapzid 12y ago

A thousand times this. If somebody were to go through the process of actually trying to implement a generic map function in the current Go they would get a good sense of just what the issues are. Unfortunately you need a good grasp of the type system and this just isn't something most of the commenters on this subject have; the Go community is much more qualified. I've done this and generics are the first road block but after consigning to working around that you run into a lot of Go implementation details around interface{} and type assertion so that what you end up with is actually quite verbose in practise and no more desirable than the alternative.. I decided that for me, for loops aren't so bad. So it does just come back around to generics but people are solving this with code generation, like gen which looks very interesting, and I imagine that is quite acceptable for the time being, for those who really want it.