Lorsque le langage Go a été créé, il a été présenté comme étant plus sûr que C et/ou C++. On peut dire sans exagérer que depuis des décennies, cet argument est quasiment toujours présent lors de la sortie d'un nouveau langage. Sauf pour les langages de script bien entendu. Mais dans la pratique, les choses sont loin d'être aussi claires et nettes.

Lors de la GopherCon 2018, Beyang Liu a fait une présentation montrant comment un bon développeur qui vient de C/C++ peut écrire du mauvais code en Go.

Du code Go, ça ressemble à du code C/C++, et, alors que Go promettait plus de sûreté, cette ressemblance est source de problèmes potentiels. Par exemple, un développeur C/C++, se basant sur son expérience avec ces langages pourra penser qu'une variable de son code Go réside dans la pile ou sur le tas, alors que ce n'est pas le cas. Par exemple :

Soit un code C++

int foo() {
    // This is a memory leak below
    int *a = new(int);
    return *a;
}

Avec l'opérateur new de C++, le développeur C++ considérera avec raison que a est sur le tas. Mais avec Go et son mot clé new emprunté à C++ cela n'est pas sûr du tout.

Soit un code similaire en Go

package main

import "fmt"

func newIntStack() *int {
    vv := new(int)
    return vv
}

func main() { fmt.Println(*newIntStack()) }

Ici, contre toute attente pour un développeur C/C++, vv réside dans la pile...

Et voilà maintenant un exemple contraire :

package main

import "fmt"

func main() {
    x := "GOPHERCON-2018"
    fmt.Println(x)
}

Tout développeur C/C++ pensera que x est dans la pile, alors qu'en fait, puisque fmt.Println utilise interface, x est transféré sur le tas.

Bien sûr quand on travaille avec un langage, on doit 'penser' dans ce langage. Mais on se demande quand même pourquoi les concepteurs d'un langage se voulant plus sûr que C/C++ on finalement créé un langage piègeux simplement parce qu'il ressemble à ceux dont il voulait éliminer les défauts :-)

La présentation complète de Beyang Liu est à lire sur SourceGraph. Un article vraiment intéressant sur les erreurs de programmations potentielles en Go pour les développeurs C/C++ et sur les répercussions de ces erreurs.