3 ms·

I'm waiting for the talks from Gophercon to appear online, but one of them[0] talks about using Go interfaces to handle most generic type problems. Another int

• wyager 13y ago
  >using Go interfaces to handle most generic type problems Do you mean Go interface specifications, or the Go interface{} type? Because the latter is the top type. Using it is equivalent to casting things to Object in Java, which people did up until 2004 when they realized it was really stupid. You also can't use Go interface specifications to make generic data structures, which is the really important use case.
  • jmoiron 13y ago
    Go does not have a type hierarchy, so there is no top type. You can easily use interface{} to make generic data structures, but interfaces have a time/space/code-complexity cost which makes them not worth it most of the time.
    • wyager 13y ago
      >Go does not have a type hierarchy, so there is no top type. Go does have a type heirarchy. It's just not very extensible. There is top (interface{}) and then there are all other types (which are subtypes of interface{}). If Go didn't have a type heirarchy, you wouldn't be able to up- and down-cast (up-casts are performed via implicit coercion to interface{} and down-casts are explicit). >You can easily use interface{} to make generic data structures, but interfaces have a time/space/code-complexity cost which makes them not worth it most of the time. You also lose any semblance of type safety, which is kind of awful.
      • jmoiron 13y ago
        There is no type hierarchy and there are no subtypes. Interfaces do not describe type relationships. The conversion required between `[]int` and `[]interface{}` further demonstrates the significance of this distinction. As for losing type safety when writing generic containers, this is true, and another reason why people don't do this.