Que le compilateur soit rapide et que le langage soit fait pour être modulaire, ça n’a rien de particulièrement nouveau comme objectif
Que le langage soit pensé de telle façon que la compilation d’une solution entière se fasse en moins d’une seconde (il ne s’agit pas d’une banale optimisation du compilateur), à l’époque où Go a été créé, il était le seul. Certes aujourd’hui ce n’est plus quelque chose de tellement novateur puisque tous les autres se sont alignés avec plus ou moins de succès, mais il ne faut pas négliger le fait que derrière Go, tu as les travaux de gens qui ont toujours eu une influence considérable sur le domaine, y compris en recherche fondamentale, depuis les années 1960 (Ken Thompson en particulier) : les snober pour le manque d’académisme sur Go a quelque chose de plutôt rigolo.
Il serait judicieux, à mon avis, de se demander comment et pourquoi ces types sont arrivés à ce résultat.
Personne n’a dit que Go était un langage inintéressant à utiliser, ce que j’ai dit c’est qu’il est inintéressant à apprendre.
Et je pense que tu te trompes lourdement à ce sujet.
C’est le seul langage que je connaisse dont les idiomes incitent délibérément à penser la concurrence de cette façon. Et d’expérience, adopter cette façon de penser dans d’autres contextes n’est pas trivial : typiquement l’equipe avec laquelle je bosse a du mal à penser de cette façon en Python, quand bien même la codebase sur laquelle on bosse a inclu ces idiomes dès sa conception (alors que je ne connaissais pas vraiment Go à cette époque… Si c’était à refaire j’aurais probablement poussé Go pour ce projet).