Google a récemment rendu public son plan de bootstrapper Go 1.5. Selon Russ Cox, l'auteur du document et Go core developer depuis 6 ans, cela fait un an que Google a planifié "la façon d'éliminer tous les programmes C des sources de Go".
Le bootstrapping est "le processus d'écrire un compilateur (ou un assembleur) dans le langage de programmation cible qu'il est censé compiler". Généralement, le bootstrapping apporte les avantages suivants :
- Tester le langage qui est bootstrappé ;
- Permettre d'écrire le compilateur dans un langage généralement plus haut niveau, donc avec des abstractions plus avancées ;
- Utiliser les améliorations du langage pour améliorer le compilateur (NdT: utiliser plutôt les améliorations du backend du compilateur pour l'améliorer lui-même).
Comme précisé, Google a démarré son initiative de supprimer tout le code C des sources de Go il y a un an, en définissant un plan en cinq phases :
Phase 1 - Développer un traducteur C->Go suffisant pour traduire le compilateur C pour Go. Cette étape est simplifiée par le fait que le compilateur ne fait pas une utilisation importante des fonctionnalités qui auraient été difficiles à porter en Go, notamment les macros, les unions ou l'arithmétique de pointeurs.
Phase 2 - Convertir le code source du compilateur, ce qui fournira un code source en Go, brut et en style C.
Phase 3 - Modifier le compilateur afin de le transformer en Go idiomatique, majoritairement en identifiant les packages, en ajoutant la documentation et les tests unitaires.
Phase 4 - Optimiser le compilateur, ce qui permettra de travailler l'utilisation mémoire et CPU du compilateur, et possiblement d'introduire la parallélisation. De plus, un essai sera fait d'"introduire une nouvelle représentation intermédiaire entre l'arbre, non-ordonné, indépendant de l'architecture (Node*s), et la liste, ordonnée et spécifique à une architecture (Prog*s), utilisés actuellement". Le but est d'améliorer les capacités d'optimisation du compilateur, par exemple dans des cas comme l'élimination de vérifications de nullité redondantes ou de vérifications de bornes.
Phase 5 - Remplacer le frontend avec les dernières versions de go/parser et go/types.
Selon Russ, d'autres alternatives à cette approche ont été considérées mais éliminées pour d'autres raisons ; elles sont détaillées dans la proposition d'il y a deux ans.
Bootstrapper Go
Bootstrapper un compilateur entraîne généralement le problème classique de "poule ou de l'oeuf", où il est nécessaire de fournir une façon de compiler le langage en cours de création.
Dans le cas de Go, pour construire Go 1.5, il sera nécessaire de disposer de Go 1.4 ou plus récent. La toolchain Go existante sera alors utilisée pour construire une version de base de la toolchain Go 1.5. Dès que cette version de base (compilée par Go 1.4) sera prête, elle sera utilisée pour se compiler elle-même, fournissant donc une toolchain Go 1.5 compilée par Go 1.5. Celle-ci sera alors utilisée pour construire go_bootstrap et les parties restantes de la bibliothèque standard et des composants Go. Ce processus, qui ajoute une étape supplémentaire correspondant à la re-compilation de la toolchain par elle-même, sera utilisé pour les futures versions de Go.
InfoQ a discuté avec Russ pour en savoir plus sur ce plan.
Le fait de se bootstrapper semble être une étape importante pour Go. Est-ce que tu peux nous expliquer pourquoi vous avez décidé de faire cet effort à ce moment précis de l'évolution du langage ?
Go est un bon langage général, mais son design a été pensé spécifiquement pour écrire des programmes serveur, concurrents et grande échelle, à l'instar de ce qui tourne sur les serveurs de Google. Si le compilateur Go avait été le premier grand programme en Go, ce cas d'utilisation aurait eu une mauvaise influence sur le design du langage, et nous aurait distraits de la vraie cible.
Il y a aussi de bonnes raisons techniques à ne pas bootstrapper tôt, comme la portabilité, la simplicité de compilation depuis les sources, et le fait d'implémenter le compilateur dans un langage stable dès le début.
Y'a-t'il des parties spécifiques dans lesquelles utiliser Go pour construire Go pourrait améliorer significativement les choses par rapport à utiliser C ?
Ken Thompson m'a dit un jour que pour écrire des programmes, Go était un langage beaucoup plus simple que C. Une raison est que Go élimine des classes entières de bugs classiques en C : les dangling pointers (NdT: pointeurs qui ne pointent plus vers un objet valide ou de type incorrect), les fuites mémoires, les dépassements de tampons ou de la pile lors de récursions importantes, les abus de void*, et bien sûr les conversions numériques non attendues.
La toolchain standard de Go a un bien meilleur support de la modularité, des tests unitaires et du profiling, que n'importe quelle toolchain C standard. Mais ce qui m'intéresse le plus, c'est la perspective de pouvoir utiliser les réécritures automatisées de programme (comme gofix) lors des modifications d'API internes, ou lors de refactorings.
Dans le document "Go 1.3+ Compiler Overhaul”, tu décris le processus en cinq phases. Peux-tu nous dire lesquelles ont déjà été terminées? Et quand est-ce que vous envisagez de terminer le reste ?
Pour le projet Go, il était plus important d'abord de convertir la runtime de C à Go, et nous sommes en train de passer au compilateur.
Pour reprendre les phases du document, nous sommes actuellement en phase 2. Le traducteur est fini, il nous a aidé à convertir la runtime, et nous sommes en train de l'appliquer au compilateur. Nous espérons avoir fini la conversion du compilateur pour Go 1.5. Le nettoyage s'ensuivra de façon continue après ça.