Go

Ouvrez un fichier qui n’existe pas en Python, open() lève un FileNotFoundError qui remonte hors de votre fonction. Faites la même chose en Go, os.ReadFile vous renvoie une valeur error accompagnée d’un slice d’octets nil. Même échec, deux formes de code complètement différentes autour. La différence n’est pas cosmétique. Elle décide si l’appelant peut ignorer l’échec par accident, et si le compilateur le repère quand ça arrive. Qu’est-ce que les exceptions et les valeurs d’erreur font réellement différemment ? Une exception est un flux de contrôle qui saute. Quelque chose échoue, la fonction lève, et l’exécution quitte la pile d’appels en cours pour atterrir dans le premier bloc catch ou except correspondant, peu importe le nombre de niveaux au-dessus. La signature de la fonction ne donne aucun indice que cela puisse arriver. loadConfig(path: string): Config en TypeScript ressemble exactement à une fonction qui ne peut pas échouer, jusqu’à ce qu’elle lève une exception pour un fichier manquant. ...

Placez go devant un appel de fonction et cette fonction s’exécute en concurrence avec le reste du programme, gérée par le runtime de Go plutôt que par le système d’exploitation. La lancer est la partie facile. La partie difficile, c’est faire passer un résultat entre deux goroutines sans qu’elles se marchent dessus sur un état partagé, et c’est le travail des channels. Qu’est-ce qu’une goroutine ? Une goroutine est une fonction qui s’exécute indépendamment de celle qui l’a lancée, gérée par le runtime de Go et non par le système d’exploitation. Un thread du système d’exploitation réserve un mégaoctet ou plus de stack et coûte au noyau un vrai temps de planification. Une goroutine démarre avec un stack d’environ 2 Ko qui grandit selon les besoins, et le runtime multiplexe de nombreuses goroutines sur une poignée de threads du système d’exploitation. En lancer des milliers à la fois est normal. ...