O Google's Go é um idioma de tipo seguro?

esta página http://golang.org/doc/go_faq.html escreve:

embora o Go tenha tipos estáticos, o idioma tenta fazer com que os tipos pareçam mais leves do que nos idiomas OO típicos

Então, minha pergunta é exatamente: ele é digitado com segurança com genéricos (como C #) ou com pouca digitação (como javascript) ou opcional (como opção estrita no Vb.Net)

— Pacerier
fonte

@JamesMcNellis ou seja, se um tipo de falha, só pode ser porque eu faço um tipo-cast (qualquer outra ação não deve causar uma exceção de tipo)

— Pacerier

@ davidk01 O Java irá compilar (1 + "boo") e o tipo bonito do Java é seguro. Essa expressão tem um significado estático definido, porque o + está sobrecarregado para objetos String pelo idioma e todos os literais primitivos podem ser elevados para objetos quebrados, que podem ser transformados em Strings.

— Trixie Wolf

Respostas:

A segurança de tipo não é um tipo de segurança em preto ou branco ou não. É mais um espectro e algumas linguagens podem ser mais seguras para tipos do que outras (e vice-versa). No entanto, acho que o que você pensa com C # vs. Javascript é provavelmente digitação estática (onde a verificação de tipo acontece no tempo de compilação) vs. digitação dinâmica (onde a verificação de tipo acontece no tempo de execução) - certamente, é sobre o que as Perguntas frequentes do Go estão falando.

O Google Go é digitado estaticamente, mas vários recursos fazem com que "pareça" ser digitado dinamicamente (pelo menos um pouco). Por exemplo, você não precisa marcar explicitamente sua classe como implementando nenhuma interface. Se as assinaturas de método da sua classe corresponderem às da interface, sua classe implementará automaticamente essa interface (uma espécie de digitação de pato). Isso é útil para estender classes internas e classes em bibliotecas de terceiros, porque você pode apenas criar sua interface para corresponder aos métodos na classe de terceiros e ela será implementada automaticamente.

A segurança do tipo é na verdade um "eixo" diferente do sistema de tipos. Por exemplo, C é uma linguagem de tipo estaticamente que não é segura para o tipo - os ponteiros permitem fazer praticamente qualquer coisa que você quiser, até mesmo as coisas que travarão seu programa. O Javascript é digitado dinamicamente, mas também é seguro para o tipo: você não pode executar operações que travarão seu programa. O C # é principalmente seguro para tipos, mas você pode marcar explicitamente áreas de código que são unsafee fazem coisas que não são mais seguras para tipos.

O Google Go também é seguro para tipos, no sentido de que você não pode mexer com tipos e travar o programa (sem acesso direto a ponteiros).

— Dean Harding
fonte

A menos que você use o pacote "inseguro", caso em que você pode travar o programa como quiser :)

— Eloff

Você pode mexer nos tipos e ter acesso aos ponteiros. E sim, você pode facilmente travar seu programa fazendo isso.

— eithed

É digitado com segurança que um tipo nunca será mal interpretado, mas um tipo incorreto pode causar pânico no programa.

— dan_waterworth
fonte

Eu não entendi, isso significa que código seguro não-tipo pode realmente ser compilado? (que não é possível em c #, a menos que nós usamos dinâmica)

— Pacerier

Fazendo afirmações tipo, tipo-wise, é basicamente como chamar um método em um tipo dinâmico

— dan_waterworth

ok então, em suma, não tem esse tipo de tipo de segurança c # permite?

— Pacerier

Isso acontece se você não fizer asserções de tipo.

— Dan_waterworth 20/05

@ Pacerier: É perfeitamente possível executar expressões digitadas incorretamente em C # sem dinâmica: basta inserir as projeções em todos os lugares (que é basicamente o que são as asserções de tipo).

— sepp2k

-1

O tipo de mapa do Go não é seguro para threads, é digitado estaticamente. Ele não possui herança de tipo, programação genérica, asserções, sobrecarga de método ou aritmética de ponteiro por um bom motivo.

Segurança de tipo e segurança de memória são objetivos de longo prazo, aqui está um problema.

A segurança de tipo apresenta uma sobrecarga, em kilobytes e megabytes, que é aceitável. O Go foi projetado com o MapReduce e o "Big Data", exobytes petabytes de dados, que apresentam problemas de desempenho com segurança de tipo, a verificação de tipo (boxing / unboxing) cria sobrecargas e retira ciclos do processamento.

A segurança do tipo pode ser restritiva na sub-digitação e polimorfismo e na tipagem de pato (converter objeto em objeto), isso cria perigos e também um espaço onde idiomas como Go são de grande benefício. C ++ e Java não estão sendo substituídos pelo Go, é uma nova linguagem para ajudar a programação distribuída e o sistema massivamente paralelo.

A grande declaração de Bruce Eckel - "Go faz muito mais sentido para a classe de problemas que C ++ originalmente pretendia resolver", é discutível. C ++ é uma linguagem muito eficiente e a implementação Boost do MapReduce é muito eficiente.

As primitivas de simultaneidade são o futuro. A segurança de tipo sempre foi um tópico muito controverso e o Go talvez seja o primeiro idioma para resolver esse problema em 20 anos ou desde Algol.

— mrhassell
fonte

Infelizmente, preciso de mais reputação para -1 nesta resposta. A segurança de tipo não é uma sobrecarga, a sobrecarga de tempo de execução definitivamente não é medida em unidades de bytes, e go possui boxe / unboxing no sentido Java. A digitação estática permite que o compilador faça mais otimizações do que uma linguagem digitada dinamicamente. A redução de mapa não está aqui nem ali, o mesmo acontece com a segurança do encadeamento.

— Eloff

O idioma de Golang de você declarar tipos usando uma interface vazia como um padrão comum para evitar a implementação de genéricos como recursos de linguagem certamente não é algo que eu consideraria "tipo seguro" e, embora possa manter a especificação de idioma simples, quando o problema surge (e deixará), deixa a complexidade na placa da pessoa que agora resta para resolver o problema com o rolo de torneira que o golang chama de recurso. Certamente não parece um idioma que foi projetado nas últimas duas décadas, porque existem idiomas que tratam da segurança de tipos de uma maneira muito melhor.

— tsturzl 19/09/19