Merci pour ton analyse je la partage sauf pour les génériques où j'avoue je n'ai pas très bien compris ton point.
Effectivement, je n'ai pas été assez clair. Je vais donner un exemple très concret avec atomic.Value qui permet de partager une valeur sans aucun lock entre plusieurs goroutine et de façon performante.
A cause d'un manque de générique, nous sommes obligés de passer interface{} (qui est le java.lang.Object de go) pour enregistrer/récupérer une valeur.
sync.Value.Store est obligé de vérifier si le type est identique à celui enregistrer la première fois et te lancera un panic (au runtime) si ce n'est pas le même type (voir cet exemple)
J'aurai préféré avoir une truc comme ci-dessous (et d'autant plus si cela ne reste pas au runtime comme Java) :
var value sync.Value<[]byte>
Pour go generate, cela reste pour ma part (c'est mon avis et c'est normal qu'il ne soit pas partagé :) ) une bidouille si tu l'utilises pour combler le manque de generics du langage.
[^] # Re: GO GO GO GO
Posté par woffer 🐧 (site web personnel) . En réponse au journal The Go Programming Language. Évalué à 2.
Effectivement, je n'ai pas été assez clair. Je vais donner un exemple très concret avec atomic.Value qui permet de partager une valeur sans aucun lock entre plusieurs goroutine et de façon performante.
A cause d'un manque de générique, nous sommes obligés de passer interface{} (qui est le java.lang.Object de go) pour enregistrer/récupérer une valeur.
sync.Value.Store est obligé de vérifier si le type est identique à celui enregistrer la première fois et te lancera un panic (au runtime) si ce n'est pas le même type (voir cet exemple)
J'aurai préféré avoir une truc comme ci-dessous (et d'autant plus si cela ne reste pas au runtime comme Java) :
var value sync.Value<[]byte>Pour
go generate, cela reste pour ma part (c'est mon avis et c'est normal qu'il ne soit pas partagé :) ) une bidouille si tu l'utilises pour combler le manque de generics du langage.