Descargo de responsabilidad: solo he jugado con Go por un día, así que hay una buena posibilidad de que me haya perdido mucho.

¿Alguien sabe por qué no hay soporte real para genéricos / plantillas / whatsInAName en Go? Entonces, hay un genérico map, pero lo proporciona el compilador, mientras que un programador de Go no puede escribir su propia implementación. Con toda la charla sobre cómo hacer que Go sea lo más ortogonal posible, ¿por qué puedo USAR un tipo genérico pero NO CREAR uno nuevo?

Especialmente cuando se trata de programación funcional, hay lambdas, incluso cierres, pero con un sistema de tipo estático que carece de genéricos, ¿cómo escribo, bueno, funciones genéricas de orden superior como filter(predicate, list)? OK, las listas vinculadas y similares se pueden hacer interface{}sacrificando la seguridad de tipos.

Como una búsqueda rápida en SO / Google no reveló ninguna idea, parece que los genéricos, en todo caso, se agregarán a Go como una ocurrencia tardía. Confío en que Thompson lo hará mucho mejor que los chicos de Java, pero ¿por qué mantener los genéricos fuera? ¿O están planeados y simplemente no implementados todavía?

esta respuesta la encontrarás aquí: http://golang.org/doc/faq#generics

¿Por qué Go no tiene tipos genéricos?

Se pueden agregar genéricos en algún momento. No sentimos urgencia por ellos, aunque entendemos que algunos programadores sí.

Los genéricos son convenientes, pero tienen un costo de complejidad en el sistema de tipos y el tiempo de ejecución. Todavía no hemos encontrado un diseño que otorgue un valor proporcional a la complejidad, aunque seguimos pensando en ello. Mientras tanto, los mapas y sectores incorporados de Go, más la capacidad de usar la interfaz vacía para construir contenedores (con unboxing explícito) significan en muchos casos que es posible escribir código que haga lo que los genéricos permitirían, si no es así.

Esto sigue siendo un problema abierto.

Ir 2

Hay un borrador de diseño para genéricos en https://blog.golang.org/go2draft .

Ir 1

Russ Cox, uno de los veteranos de Go, escribió una publicación en el blog titulada El dilema genérico , en la que pregunta

... ¿quieres programadores lentos, compiladores lentos y binarios hinchados, o tiempos de ejecución lentos?

Los programadores lentos son el resultado de no genéricos, los compiladores lentos son causados ​​por C ++ como los genéricos y los tiempos de ejecución lentos se derivan del enfoque de boxeo-unboxing que utiliza Java.

La cuarta posibilidad no mencionada en el blog es ir a la ruta C #. Generando el código especializado como en C ++, pero en tiempo de ejecución cuando es necesario. Realmente me gusta, pero Go es muy diferente a C #, por lo que probablemente esto no sea aplicable en absoluto ...

Debo mencionar que el uso de la popular técnica similar a Java 1.4 de programación genérica en el camino que interface{}sufre sufre exactamente los mismos problemas que el boxeo-unboxing (porque eso es lo que estamos haciendo), además de la pérdida de seguridad de tipo de tiempo de compilación. Para tipos pequeños (como ints), Go optimiza el interface{}tipo de modo que una lista de ints que se enviaron a la interfaz {} ocupa un área contigua de memoria y ocupa solo el doble de espacio que los ints normales. Sin embargo, todavía existe la sobrecarga de las comprobaciones de tiempo de ejecución durante la transmisión interface{}. Referencia .

Todos los proyectos que agregan soporte genérico para ir (hay varios de ellos y todos son interesantes) siguen de manera uniforme la ruta C ++ de generación de código de tiempo de compilación.

Aunque los genéricos no están incorporados actualmente, existen varias implementaciones externas de genéricos para llevar, que utilizan comentarios en combinación con pequeñas utilidades que generan código.

Aquí hay una de esas implementaciones: http://clipperhouse.github.io/gen/

En realidad, de acuerdo con este post:

Muchas personas han concluido (incorrectamente) que la posición del equipo de Go es "Go nunca tendrá genéricos". Por el contrario, entendemos los potenciales genéricos que tienen, tanto para hacer que Go sea mucho más flexible y poderoso y para hacer que Go sea mucho más complicado. Si vamos a agregar genéricos, queremos hacerlo de manera que obtenga tanta flexibilidad y potencia con la menor complejidad posible.

El polimorfismo paramétrico (genéricos) está bajo consideración para Go 2 .

Este enfoque introduciría el concepto de un contrato , que puede usarse para expresar restricciones en los parámetros de tipo:

contract Addable(a T) {
  a + a // Could be += also
}

Tal contrato podría entonces usarse así:

func Sum(type T Addable)(l []T) (total T) {
  for _, e := range l {
    total += e
  }
  return total
}

Esta es una propuesta en esta etapa.

Su filter(predicate, list)función podría implementarse con un parámetro de tipo como este:

func Filter(type T)(f func(T) bool, l []T) (result []T) {
  for _, e := range l {
    if f(e) {
      result = append(result, e)
    }
  }
  return result
}

En este caso, no hay necesidad de restringir T.