¿Google's Go es un idioma de tipo seguro?

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)

— Pacerier
fuente

@JamesMcNellis significa que si un tipo falla, solo puede ser porque hago una conversión de tipo (cualquier otra acción no debería causar una excepción de tipo)

— Pacerier

@ davidk01 Java compilará (1 + "boo"), y el tipo bastante seguro de Java. Esa expresión tiene un significado estático definido porque el lenguaje sobrecarga + para los objetos de cadena, y todos los literales primitivos se pueden levantar a tipos de objetos envueltos que luego se pueden convertir en cadenas.

— Trixie Wolf

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).

— Dean Harding
fuente

A menos que use el paquete "inseguro", en cuyo caso puede bloquear el programa de la forma que desee :)

— Eloff

Usted puede perder el tiempo con los tipos y no tienen acceso a los punteros. Y sí, puede bloquear fácilmente su programa haciendo eso.

— Publicado el

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.

— dan_waterworth
fuente

no lo entiendo, ¿significa que se puede compilar un código seguro que no sea de tipo? (que no es posible en C # a menos que usemos dinámicas)

— Pacerier

Hacer aserciones de tipo

— términos de

ok, entonces, en resumen, ¿no tiene ese tipo de seguridad de tipo que permite C #?

— Pacerier

Lo hace si no haces aserciones de tipo.

— dan_waterworth

@Pacerier: es perfectamente posible ejecutar expresiones mal escritas en C # sin dinámicas: simplemente inserte conversiones en todas partes (que es básicamente lo que son las aserciones de tipo).

— sepp2k

-1

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.

— mrhassell
fuente

Lamentablemente necesito más reputación para -1 esta respuesta. La seguridad de tipo no es una sobrecarga, la sobrecarga del tiempo de ejecución definitivamente no se mide en unidades de bytes, y go tiene boxing / unboxing en el sentido de Java. La escritura estática permite que el compilador realice más optimizaciones que un lenguaje escrito dinámicamente. La reducción del mapa no está ni aquí ni allá, lo mismo ocurre con la seguridad del hilo.

— Eloff

La expresión idiomática de Golang de hacerte afirmar tipos usando una interfaz vacía como patrón común para evitar la implementación de genéricos como características del lenguaje ciertamente no es algo que yo consideraría "tipo seguro", y si bien puede mantener la especificación del lenguaje simple, cuando el problema surge (y lo hará) deja la complejidad en el plato de la persona que ahora queda para resolver el problema con el rollo de conducto, el golang llama una característica. Ciertamente no parece un lenguaje diseñado en las últimas 2 décadas, porque hay idiomas que abordan la seguridad de los tipos de una manera mucho mejor.

— tsturzl