esta página http://golang.org/doc/go_faq.html escribe:
aunque Go tiene tipos estáticos, el lenguaje intenta hacer que los tipos se sientan más livianos que en los lenguajes OO típicos
Entonces, mi pregunta es exactamente si se escribe de forma segura con genéricos (como C #) o si se escribe de forma suelta (como JavaScript) u opcional (como la opción estricta en Vb.Net)
programming-languages
algorithms
google
go
type-safety
Pacerier
fuente
fuente
Respuestas:
La seguridad de tipo no es segura en negro o blanco o no. Es más un espectro y algunos idiomas pueden ser más seguros de tipo que otros (y viceversa). Sin embargo, creo que lo que estás pensando con C # frente a Javascript es probablemente una escritura estática (donde la verificación de tipo ocurre en tiempo de compilación) frente a una escritura dinámica (donde la verificación de tipo ocurre en tiempo de ejecución), ciertamente, eso es de qué están hablando las preguntas frecuentes de Go.
Google Go está estáticamente tipado, pero una serie de características hacen que "parezca" estar (al menos algo) tipado dinámicamente. Por ejemplo, no necesita marcar explícitamente su clase como implementando ninguna interfaz. Si las firmas de método de su clase coinciden con las de la interfaz, entonces su clase implementa automáticamente esa interfaz (una especie de tipeo de pato). Esto es útil para ampliar las clases integradas y las clases en bibliotecas de terceros, ya que puede crear su interfaz para que coincida con los métodos de la clase de terceros y la implementará automáticamente.
La seguridad de tipos es en realidad un "eje" diferente del sistema de tipos. Por ejemplo, C es un lenguaje de tipo estático que no es seguro para escribir: los punteros le permiten hacer casi cualquier cosa que desee, incluso cosas que bloquean su programa. Javascript se escribe dinámicamente, pero también es seguro: no puede realizar operaciones que bloqueen su programa. C # es principalmente de tipo seguro, pero puede marcar explícitamente áreas de código que son
unsafey hacen cosas que ya no son de tipo seguro.Google Go también es de tipo seguro en el sentido de que no puede perder el tiempo con los tipos y bloquear el programa (sin acceso directo a los punteros).
fuente
Se escribe de manera segura para que un tipo nunca se malinterprete, pero un tipo incorrecto puede causar que el programa entre en pánico.
fuente
El tipo de mapa de Go no es seguro para subprocesos, está tipado estáticamente. No , no tiene tipo de herencia, la programación genérica, las afirmaciones, la sobrecarga de métodos, o bien la aritmética de punteros y por buenas razones.
La seguridad de tipos y la seguridad de la memoria son objetivos a largo plazo, aquí hay un problema.
La seguridad de tipo presenta una sobrecarga, en kilobytes y megabytes, que es aceptable. Go está diseñado con MapReduce y "Big data", exobytes y petabytes de datos, lo que presenta problemas de rendimiento con la seguridad de tipos, la verificación de tipos (boxing / unboxing) crea gastos generales y elimina los ciclos de procesamiento.
La seguridad de tipos puede ser restrictiva en subtipados y polimorfismos y en tipeos de pato (lanzar objeto a objeto), esto crea peligros y también un espacio donde los lenguajes como Go son de gran beneficio. C ++ y Java no están siendo reemplazados por Go, es un nuevo lenguaje para ayudar a la programación distribuida y al sistema paralelo masivo.
La gran declaración de Bruce Eckel: "Go tiene mucho más sentido para la clase de problemas que C ++ originalmente tenía la intención de resolver" es discutible. C ++ es un lenguaje muy eficiente y la implementación Boost de MapReduce es muy eficiente.
Las primitivas de concurrencia son el futuro. La seguridad de tipografía siempre ha sido un tema muy polémico y quizás sea el primer idioma en abordar este problema en 20 años, o desde Algol.
fuente