Perché niente farmaci generici in Go?

Disclaimer: ho giocato con Go per un solo giorno ora, quindi ci sono buone probabilità che mi sia mancato molto.

Qualcuno sa perché non c’è un vero supporto per generici / modelli / whatsInAName in Go? Quindi c’è una map generica, ma fornita dal compilatore, mentre un programmatore Go non può scrivere la propria implementazione. Con tutti i discorsi su come rendere Go il più ortogonale ansible, perché posso UTILIZZARE un tipo generico ma non CREARE uno nuovo?

Soprattutto quando si tratta di programmazione funzionale, ci sono lambda, anche chiusure, ma con un sistema di tipo statico privo di generici, come faccio a scrivere, bene, funzioni generiche di ordine superiore come filter(predicate, list) ? OK, le liste collegate e simili possono essere fatte con l’ interface{} sacrifica la sicurezza del tipo.

Come una rapida ricerca su SO / Google non ha rivelato alcun approfondimento, sembra che i generici, se non del tutto, saranno aggiunti a Go in un secondo momento. Mi fido di Thompson per fare meglio dei ragazzi Java, ma perché tenere fuori i farmaci generici? O sono pianificati e non ancora implementati?

questa risposta troverai qui: http://golang.org/doc/faq#generics

Perché Go non ha tipi generici?

Generics può essere aggiunto a un certo punto. Non sentiamo un’urgenza per loro, anche se capiamo che alcuni programmatori lo fanno.

I generici sono convenienti ma hanno un costo in termini di complessità nel sistema di tipi e nel tempo di esecuzione. Non abbiamo ancora trovato un design che dia valore proporzionato alla complessità, anche se continuiamo a pensarci. Nel frattempo, le mappe e le sezioni integrate di Go, oltre alla possibilità di utilizzare l’interfaccia vuota per build container (con un univoco esplicito) significano in molti casi che è ansible scrivere codice che fa ciò che i generici consentirebbero, se meno agevolmente.

Questo rimane un problema aperto.

Russ Cox, uno dei veterani del Go, ha scritto un post sul blog intitolato The Generic Dilemma , in cui chiede

… vuoi programmatori lenti, compilatori lenti e binari gonfiati, o tempi di esecuzione lenti?

I programmatori lenti sono il risultato di no generici, i compilatori lenti sono causati da generici come C ++ e tempi di esecuzione lenti derivano dall’approccio boxing-unboxing utilizzato da Java.

La quarta possibilità non menzionata nel blog sta andando al percorso C #. Generazione del codice specializzato come in C ++, ma in fase di esecuzione quando è necessario. Mi piace molto, ma Go è molto diverso da C # quindi probabilmente non è applicabile a tutti …

Devo dire che l’uso della popolare tecnica Java 1.4 di programmazione generica in go that cast a interface{} soffre esattamente degli stessi problemi di boxing-unboxing (perché è quello che stiamo facendo), oltre alla perdita di sicurezza del tipo a tempo di compilazione. Per i tipi piccoli (come ints) Go ottimizza il tipo di interface{} modo che un elenco di interi che sono stati trasmessi all’interfaccia {} occupi un’area contigua di memoria e occupa solo il doppio dello spazio dei normali inti. C’è ancora il sovraccarico dei controlli di runtime durante la trasmissione interface{} , però. Riferimento

Tutti i progetti che aggiungono supporto generico per andare (ce ne sono molti e tutti sono interessanti) vanno uniformsmente nella rotta C ++ della generazione del codice di tempo compilato.

Anche se i generici non sono attualmente integrati, ci sono diverse implementazioni esterne di generici per go, che usano commenti in combinazioni con piccole utility che generano codice.

Ecco una di queste implementazioni: http://clipperhouse.github.io/gen/