4 ms·

It seems like due to lack of generics I see more and more interface{} and reflection stuff in code bases. This is getting ridiculous. I've written a lot of Go.

by eknkc 10y ago

It seems like due to lack of generics I see more and more interface{} and reflection stuff in code bases. This is getting ridiculous. I've written a lot of Go. Tried my best to stick to what language provides but at some point you say "screw it" and start fighting with the language. That is never a good sign.

twblalock 10y ago
interface{} is the new void*. There are far better ways to handle generics in modern languages, which preserve type safety and aren't very cumbersome.
- masklinn 10y ago
  > interface{} is the new void*. More like Java's Object, especially since downcasts are mandatorily runtime-checked. And the results are exactly what one could have expected from the first 10 years of java (if slightly subdued as Java only had a single magical blessed buildin type) given the language is in more or less the same class.
  - mseepgood 10y ago
    More like C#'s "object" than Java's "Object".
- leaveyou 10y ago
  >interface{} is the new void* There is an important difference between interface{} and void* which makes it a lot less reckless. AFAIK interface{} contains not only a pointer to data but also a reference to the type of the data. Therefore you can cast that data safely to the original type (or use "switch" on the type). if origData, ok := data.(OriginalType); ok { /safe to use origData here*/ }
interactiv 10y ago
yep, I wrote this : https://github.com/Mparaiso/lodash-go https://github.com/Mparaiso/lodash-go which is in theory "runtime type safe" in the sense that is yields an error if types do not match , but it uses reflection which leads to a huge performance hit. The irony is that Go is a perfectly capable functional language when one opts out of Go type system. (Don't use that package, this is not idiomatic Go).
- burntsushi 10y ago
  See also: http://blog.burntsushi.net/type-parametric-functions-golang/ http://blog.burntsushi.net/type-parametric-functions-golang/
  - interactiv 10y ago
    Yes, if you look at the source code I use unification to tell whether types match or not.
    - burntsushi 10y ago
      You're doing a lot of repeated work though. I was trying to point out this function, which does unification in a generic context, given some function type: https://godoc.org/github.com/BurntSushi/ty#Check https://godoc.org/github.com/BurntSushi/ty#Check ... For example, it reduces a lot of the reflection boiler plate: https://github.com/BurntSushi/ty/blob/master/fun/list.go#L80 https://github.com/BurntSushi/ty/blob/master/fun/list.go#L80
shurcooL 10y ago
Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms. Perhaps that's a reason I'm motivated to desire less language changes.
- omarforgotpwd 10y ago
  I'm curious, what platform do you want to go to support that it doesn't already? Platform support seems pretty good already, at least for my needs.
  - shurcooL 10y ago
    A really big and popular platform where Go isn't officially supported yet is the web (browser). I'm trying to push that direction as much as I can by contributing to GopherJS [0], which is IMO our best bet until wasm [1] comes out and has adds support for GC languages [2]. I agree the rest of the platform support is absolutely fantastic. We have the big 3 desktop OSes, as well as iOS and Android already. But so much of what we do today is on the web, and I don't want to keep using JavaScript or to keep crossing the Go <-> JS boundary inconsistencies. That's not the kind of future I want to invest in. [0] https://github.com/gopherjs/gopherjs#readme https://github.com/gopherjs/gopherjs#readme [1] https://webassembly.github.io/ https://webassembly.github.io/ [2] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...
- coldtea 10y ago
  >Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.
  - eknkc 10y ago
    Also, I'm generally fine with language tradeoffs, If there is a good reason that I need to copy paste something, so be it. I'll do it. Go and Generics issue on the other hand, feels a little different to me. It is a solved problem. Go does not have an inherent show stopper for generics. It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.

by eknkc 10y ago

twblalock 10y ago

interface{} is the new void*. There are far better ways to handle generics in modern languages, which preserve type safety and aren't very cumbersome.

masklinn 10y ago
> interface{} is the new void*. More like Java's Object, especially since downcasts are mandatorily runtime-checked. And the results are exactly what one could have expected from the first 10 years of java (if slightly subdued as Java only had a single magical blessed buildin type) given the language is in more or less the same class.
- mseepgood 10y ago
  More like C#'s "object" than Java's "Object".
leaveyou 10y ago
>interface{} is the new void* There is an important difference between interface{} and void* which makes it a lot less reckless. AFAIK interface{} contains not only a pointer to data but also a reference to the type of the data. Therefore you can cast that data safely to the original type (or use "switch" on the type). if origData, ok := data.(OriginalType); ok { /safe to use origData here*/ }

interactiv 10y ago

yep, I wrote this : https://github.com/Mparaiso/lodash-go https://github.com/Mparaiso/lodash-go which is in theory "runtime type safe" in the sense that is yields an error if types do not match , but it uses reflection which leads to a huge performance hit. The irony is that Go is a perfectly capable functional language when one opts out of Go type system. (Don't use that package, this is not idiomatic Go).

burntsushi 10y ago
See also: http://blog.burntsushi.net/type-parametric-functions-golang/ http://blog.burntsushi.net/type-parametric-functions-golang/
- interactiv 10y ago
  Yes, if you look at the source code I use unification to tell whether types match or not.
  - burntsushi 10y ago
    You're doing a lot of repeated work though. I was trying to point out this function, which does unification in a generic context, given some function type: https://godoc.org/github.com/BurntSushi/ty#Check https://godoc.org/github.com/BurntSushi/ty#Check ... For example, it reduces a lot of the reflection boiler plate: https://github.com/BurntSushi/ty/blob/master/fun/list.go#L80 https://github.com/BurntSushi/ty/blob/master/fun/list.go#L80

shurcooL 10y ago

Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms. Perhaps that's a reason I'm motivated to desire less language changes.

omarforgotpwd 10y ago
I'm curious, what platform do you want to go to support that it doesn't already? Platform support seems pretty good already, at least for my needs.
- shurcooL 10y ago
  A really big and popular platform where Go isn't officially supported yet is the web (browser). I'm trying to push that direction as much as I can by contributing to GopherJS [0], which is IMO our best bet until wasm [1] comes out and has adds support for GC languages [2]. I agree the rest of the platform support is absolutely fantastic. We have the big 3 desktop OSes, as well as iOS and Android already. But so much of what we do today is on the web, and I don't want to keep using JavaScript or to keep crossing the Go <-> JS boundary inconsistencies. That's not the kind of future I want to invest in. [0] https://github.com/gopherjs/gopherjs#readme https://github.com/gopherjs/gopherjs#readme [1] https://webassembly.github.io/ https://webassembly.github.io/ [2] https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...
coldtea 10y ago
>Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.
- eknkc 10y ago
  Also, I'm generally fine with language tradeoffs, If there is a good reason that I need to copy paste something, so be it. I'll do it. Go and Generics issue on the other hand, feels a little different to me. It is a solved problem. Go does not have an inherent show stopper for generics. It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.