3 ms·

>Go’s lack of generics means that you have to write mapStringToString as a mapper between collections of two fixed types – you can’t write a generic map from an

by daenz 8y ago

>Go’s lack of generics means that you have to write mapStringToString as a mapper between collections of two fixed types – you can’t write a generic map from an array of T to an array of R, as you can in almost any other strongly-typed modern language. That's not true. Here's their example written to be more generic: func mapThingToThing(inSlice interface{}, mapperFn interface{}) []interface{} { mapper := reflect.ValueOf(mapperFn) input := reflect.ValueOf(inSlice) output := make([]interface{}, input.Len()) for i := 0; i < input.Len(); i++ { item := input.Index(i) output[i] = mapper.Call([]reflect.Value{item})[0] } return output } and calling: fn := func(item string) string { return item + "!" } res := mapThingToThing([]string{"a", "b", "c"}, fn) for _, item := range res { fmt.Printf("item = %+v\n", item) } I didn't say it was pretty or good, but it can be done. Really confused by the downvotes.

dagss 8y ago
Well technically this is reflection which is something else than generics. You say "that's not true" but it IS true that go lack generics (or metaprogramming in general). You point out that it supports reflection which is something else... it is a bit like coding in Python, you loose compile time type safety.
- deleted 8y ago
  [deleted]
- daenz 8y ago
  No, it's not generics, but it enables you to write a generic function, which is what the article claimed was not possible in Go.
stephen 8y ago
> Really confused by the downvotes It's not type safe. Any other modern/static language would use generics to ensure inSlice and mapperFn both operate on the same types. People downvoting you probably see this as obvious for programmers that want/choose a static language like Go/Java/TypeScript/etc.
- daenz 8y ago
  >It's not type safe. Yes, I get that, but that's also moving the goalpost. The post claimed that "you can’t write a generic map from an array of T to an array of R", but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). I think the author just didn't know that this was possible, or his concern would have been about the lack of type safety with the reflection method.
  - nostalgeek 8y ago
    > Yes, I get that, but that's also moving the goalpost. no it is not. The whole point of generic programming is compile time type safety for incomplete types. > but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). not in a compile time type safe way. Again, you can't negate the whole point of generics, that's a cop-out. You just wrote Python like dynamic code in Go here, with reflection (AKA runtime behavior) which incures a severe performance penalty. And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. If you really want to write a generic mapper the only serious way to do that in go is to use reflect.MakeFunc then a function variable of the choosen signature. But again reflection is so slow it's not even worth to begin with.
    - daenz 8y ago
      >no it is not. The whole point of generic programming is compile time type safety for incomplete types. Except that's not what the post's gripe was about. His gripe was that you need to write a new function for every type you want to map, because there's no way to write one that is generic for all types. He doesn't mention type safety at all, so yes, the solution I posted meets the goal of his complaint. >And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. Did you miss the point where I said "it's not good or pretty" ? Or do you just want to bitch about everything? Your whole post reads like someone who has never written a container type in Go. Guess how you do it? You use interface{} and cast in the caller!
ecnahc515 8y ago
Unfortunately, to do anything with the results you have to iterate over them again to convert back into a slice of non-empty interfaces, making this implementation basically useless.
- daenz 8y ago
  >basically useless It is how container types are done in Go.
  - nostalgeek 8y ago
    > It is how container types are done in Go. You can't define your own compile type safe container types in Go at first place. You demonstrated nothing with your piece of code, you just wrote some dynamic stuff that doesn't care about types, this isn't a container type, you ignore the type of the element.
    - daenz 8y ago
      >You demonstrated nothing with your piece of code I've demonstrated how you map a function over a list containing any type. How would you do it? Provide a solution.
      - nostalgeek 8y ago
        > I've demonstrated how you map a function over a list containing any type. How would you do it? Provide a solution. you've demonstrated you are unable to do it while conserving the type of an element. You iterate over an array with a range loop which allows the code to stay compile time safe. That's the only thing one can call idiomatic go code here. You threw out compile time safety for nothing trying to prove some point that makes no sense to begin with.

by daenz 8y ago

dagss 8y ago

Well technically this is reflection which is something else than generics. You say "that's not true" but it IS true that go lack generics (or metaprogramming in general). You point out that it supports reflection which is something else... it is a bit like coding in Python, you loose compile time type safety.

deleted 8y ago
[deleted]
daenz 8y ago
No, it's not generics, but it enables you to write a generic function, which is what the article claimed was not possible in Go.

stephen 8y ago

> Really confused by the downvotes It's not type safe. Any other modern/static language would use generics to ensure inSlice and mapperFn both operate on the same types. People downvoting you probably see this as obvious for programmers that want/choose a static language like Go/Java/TypeScript/etc.

daenz 8y ago
>It's not type safe. Yes, I get that, but that's also moving the goalpost. The post claimed that "you can’t write a generic map from an array of T to an array of R", but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). I think the author just didn't know that this was possible, or his concern would have been about the lack of type safety with the reflection method.
- nostalgeek 8y ago
  > Yes, I get that, but that's also moving the goalpost. no it is not. The whole point of generic programming is compile time type safety for incomplete types. > but you can (if you take generic to mean "general" and not "specifically using the mechanism of generics"). not in a compile time type safe way. Again, you can't negate the whole point of generics, that's a cop-out. You just wrote Python like dynamic code in Go here, with reflection (AKA runtime behavior) which incures a severe performance penalty. And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. If you really want to write a generic mapper the only serious way to do that in go is to use reflect.MakeFunc then a function variable of the choosen signature. But again reflection is so slow it's not even worth to begin with.
  - daenz 8y ago
    >no it is not. The whole point of generic programming is compile time type safety for incomplete types. Except that's not what the post's gripe was about. His gripe was that you need to write a new function for every type you want to map, because there's no way to write one that is generic for all types. He doesn't mention type safety at all, so yes, the solution I posted meets the goal of his complaint. >And let's not get started on the fact that you're returning []interface{} which is often pretty useless when the type of the element matters. You introduced some serious code smell with that function since you threw away type safety. Did you miss the point where I said "it's not good or pretty" ? Or do you just want to bitch about everything? Your whole post reads like someone who has never written a container type in Go. Guess how you do it? You use interface{} and cast in the caller!

ecnahc515 8y ago

Unfortunately, to do anything with the results you have to iterate over them again to convert back into a slice of non-empty interfaces, making this implementation basically useless.

daenz 8y ago
>basically useless It is how container types are done in Go.
- nostalgeek 8y ago
  > It is how container types are done in Go. You can't define your own compile type safe container types in Go at first place. You demonstrated nothing with your piece of code, you just wrote some dynamic stuff that doesn't care about types, this isn't a container type, you ignore the type of the element.
  - daenz 8y ago
    >You demonstrated nothing with your piece of code I've demonstrated how you map a function over a list containing any type. How would you do it? Provide a solution.
    - nostalgeek 8y ago
      > I've demonstrated how you map a function over a list containing any type. How would you do it? Provide a solution. you've demonstrated you are unable to do it while conserving the type of an element. You iterate over an array with a range loop which allows the code to stay compile time safe. That's the only thing one can call idiomatic go code here. You threw out compile time safety for nothing trying to prove some point that makes no sense to begin with.