Google's Go è una lingua sicura?

questa pagina http://golang.org/doc/go_faq.html scrive:

sebbene Go abbia tipi statici, la lingua tenta di far sembrare i tipi più leggeri rispetto alle lingue OO tipiche

Quindi la mia domanda è esattamente se è tipizzato in modo sicuro con generici (come C #) o liberamente (come javascript) o opzionale (come l'opzione rigorosa in Vb.Net)

— Pacerier
fonte

@JamesMcNellis significa che se un tipo fallisce, può essere solo perché faccio un cast di tipo (qualsiasi altra azione non dovrebbe causare un'eccezione di tipo)

— Pacerier

@ davidk01 Java verrà compilato (1 + "boo"), e il bel tipo di Java è sicuro. Quell'espressione ha un significato statico definito perché + è sovraccarico per gli oggetti String dal linguaggio e tutti i letterali primitivi possono essere sollevati dal tipo in oggetti avvolti che possono quindi essere trasformati in stringhe.

— Trixie Wolf,

Risposte:

La sicurezza del tipo non è o meno sicura per il bianco o nero. È più di uno spettro e alcune lingue possono essere più sicure dei tipi rispetto ad altre (e viceversa). Tuttavia, penso che ciò a cui stai pensando con C # vs. Javascript sia probabilmente la tipizzazione statica (dove il controllo del tipo avviene in fase di compilazione) rispetto alla digitazione dinamica (dove il controllo del tipo avviene in fase di esecuzione) - certamente, questo è di cosa parla la FAQ di Go.

Google Go è tipizzato staticamente, ma una serie di funzioni lo fanno "apparire" come (almeno in qualche modo) digitato in modo dinamico. Ad esempio, non è necessario contrassegnare esplicitamente la classe come implementazione di interfacce. Se le firme dei metodi della tua classe coincidono con quelle dell'interfaccia, allora la tua classe implementa automaticamente quell'interfaccia (una specie di duck-typing). Questo è utile per estendere le classi e le classi incorporate nelle librerie di terze parti, perché puoi semplicemente creare la tua interfaccia per abbinare i metodi sulla classe di terze parti e la implementerà automaticamente.

La sicurezza del tipo è in realtà un "asse" diverso del sistema di tipi. Ad esempio, C è un linguaggio di tipo statico che non è sicuro per i tipi: i puntatori ti consentono di fare praticamente tutto ciò che ti piace, anche cose che potrebbero causare l'arresto anomalo del programma. Javascript viene digitato in modo dinamico, ma è anche sicuro per i tipi: non è possibile eseguire operazioni che causano l'arresto anomalo del programma. C # è per lo più sicuro, ma è possibile contrassegnare esplicitamente aree di codice che sono unsafee fare cose che non sono più sicure.

Google Go è anche sicuro per i tipi, nel senso che non puoi scherzare con i tipi e bloccare il programma (nessun accesso diretto ai puntatori).

— Dean Harding
fonte

A meno che non utilizzi il pacchetto "non sicuro", nel qual caso puoi

— interrompere

È possibile pasticciare con i tipi e non hanno accesso ai puntatori. E sì, puoi facilmente mandare in crash il tuo programma.

— Eithed

Si digita in modo sicuro che un tipo non verrà mai frainteso, ma un tipo errato può causare il panico nel programma.

— dan_waterworth
fonte

non capisco, significa che un codice sicuro non di tipo può effettivamente essere compilato? (che non è possibile in c # a meno che non utilizziamo la dinamica)

— Pacerier,

Fare asserzioni di tipo, per quanto riguarda il tipo, è fondamentalmente come chiamare un metodo su un tipo dinamico

— dan_waterworth

ok quindi insomma non ha quel tipo di sicurezza che il c # consente?

— Pacerier,

Lo fa se non digiti asserzioni.

— dan_waterworth,

@Pacerier: è perfettamente possibile eseguire espressioni con errori di digitazione in C # senza dinamiche: basta inserire i cast ovunque (che è fondamentalmente che tipo di affermazioni sono).

— sepp2k,

-1

Il tipo di mappa di Go non è thread-safe, è staticamente digitato. Esso non ha tipo di ereditarietà, programmazione generica, asserzioni, sovraccarico metodo, o puntatori sia e per buoni motivi.

La sicurezza del tipo e la sicurezza della memoria sono obiettivi a lungo termine, qui un problema si trova.

La sicurezza del tipo presenta un sovraccarico, in kilobyte e megabyte, che è accettabile. Go è progettato con MapReduce e "Big data", esobita un petabyte di dati, che presenta problemi di prestazioni con la sicurezza del tipo, il controllo del tipo (boxing / unboxing) crea spese generali e porta via i cicli dall'elaborazione.

La sicurezza dei tipi può essere restrittiva nella sotto-tipizzazione e nel polimorfismo e nella digitazione delle anatre (oggetto da getto a oggetto), questo crea pericoli e anche uno spazio in cui linguaggi come Go sono di grande beneficio. C ++ e Java non vengono sostituiti da Go, è un nuovo linguaggio per aiutare la programmazione distribuita e il sistema fortemente parallelo.

La grande dichiarazione di Bruce Eckel - "Go ha molto più senso per la classe di problemi che il C ++ era originariamente destinato a risolvere", è discutibile. C ++ è un linguaggio molto efficiente e l'implementazione Boost di MapReduce è molto efficiente.

Le primitive della concorrenza sono il futuro. La sicurezza dei tipi è sempre stata un argomento molto controverso e Go forse è la prima lingua ad affrontare questo problema in 20 anni, o da quando Algol.

— mrhassell
fonte

Purtroppo ho bisogno di più reputazione per -1 questa risposta. La sicurezza del tipo non è un overhead, l'overhead di runtime non è sicuramente misurato in unità di byte e go ha boxing / unboxing in senso Java. La digitazione statica consente al compilatore di apportare più ottimizzazioni rispetto a un linguaggio tipizzato in modo dinamico. La riduzione della mappa non è né qui né lì, idem con sicurezza dei thread.

— Eloff,

Il linguaggio di Golang di farti affermare i tipi usando un'interfaccia vuota come modello comune per evitare l'implementazione dei generici come caratteristiche del linguaggio non è certamente qualcosa che considererei "sicuro", e mentre può rendere semplici le specifiche del linguaggio, quando il problema Sorge (e lo farà) lascia la complessità sul piatto della persona che ora è rimasta per risolvere il problema con il lancio del dotto che il golang chiama una caratteristica. Certamente non sembra una lingua progettata negli ultimi 2 decenni, perché ci sono lingue che affrontano la sicurezza dei tipi in un modo molto migliore.

— tsturzl,