Ma question: quel type d'application nécessite autant de threads d'exécution simultanés?
1) Le fait qu'une langue «évolue» signifie qu'il y a moins de chances que vous ayez à abandonner cette langue lorsque les choses deviennent plus complexes en cours de route. (C'est ce qu'on appelle le concept de «produit entier».) Beaucoup de gens abandonnent Apache pour Nginx pour cette raison. Si vous êtes proche de la «limite stricte» imposée par la surcharge des threads, vous aurez peur et commencerez à réfléchir aux moyens de la dépasser. Les sites Web ne peuvent jamais prédire le trafic qu'ils obtiendront, il est donc raisonnable de passer un peu de temps à rendre les choses évolutives.
2) Un goroutine par demande juste le début. Il existe de nombreuses raisons d'utiliser les goroutines en interne.
- Envisagez une application web avec 100 requêtes simultanées, mais chaque requête génère des centaines de requêtes back-end. L'exemple évident est un agrégateur de moteur de recherche. Mais à peu près n'importe quelle application pourrait créer des goroutines pour chaque "zone" à l'écran, puis les générer indépendamment au lieu de séquentiellement. Par exemple, chaque page sur Amazon.com est composée de plus de 150 demandes principales, assemblées juste pour vous. Vous ne le remarquez pas car ils sont en parallèle, pas séquentiels, et chaque "zone" est son propre service web.
- Considérez toute application où la fiabilité et la latence sont primordiales. Vous souhaitez probablement que chaque demande entrante déclenche quelques demandes principales et renvoie les données qui reviennent en premier .
- Tenez compte de toute «jointure client» effectuée dans votre application. Au lieu de dire "pour chaque élément, obtenez des données", vous pouvez créer un tas de goroutines. Si vous avez un tas de bases de données esclaves à interroger, vous irez magiquement N fois plus vite. Sinon, ce ne sera pas plus lent.
atteindre des rendements décroissants lorsque le nombre de threads / processus est beaucoup plus élevé que le nombre de cœurs physiques
Les performances ne sont pas la seule raison de diviser un programme en CSP . Cela peut en fait rendre le programme plus facile à comprendre et certains problèmes peuvent être résolus avec beaucoup moins de code.
Comme dans les diapositives liées ci-dessus, avoir la concurrence dans votre code est un moyen d'organiser le problème. Ne pas avoir de goroutines, c'est comme ne pas avoir de structure de données Carte / Dictonary / Hash dans votre langue. Vous pouvez vous en passer. Mais une fois que vous l'avez, vous commencez à l'utiliser partout, et cela simplifie vraiment votre programme.
Dans le passé, cela signifiait «lancer votre propre» programmation multithread. Mais c'était complexe et dangereux - il n'y a toujours pas beaucoup d'outils pour s'assurer que vous ne créez pas de courses. Et comment empêcher un futur responsable de faire une erreur? Si vous regardez des programmes grands / complexes, vous verrez qu'ils dépensent BEAUCOUP de ressources dans cette direction.
Étant donné que la concurrence n'est pas une partie de première classe de la plupart des langues, les programmeurs d'aujourd'hui ont un angle mort pour savoir pourquoi cela leur serait utile. Cela ne fera que devenir plus évident que chaque téléphone et montre-bracelet se dirige vers 1000 cœurs. Partez avec un outil de détection de course intégré.