Je ne pense pas que le Go et le C++ jouent dans la même cours.
Go ne sera jamais rapide comme le C/C++/Rust/(ajouter ici le langage de votre choix).
Pour moi, le Go brille dans les domaines où les applications passent la majorité de leurs temps à attendre les entrées/sorties (I/O bound) et dans des environnements d’exécution contraints (i.e. tournant sur des pods avec 50 millicpu & 50 mo de ram parce que ça coûte moins cher chez AWS/GCP/Azur/on-premise/(ajouter ici le cloud provider de votre choix). Dans ce domaines, Go permet très facilement de gérer ce genre de problèmes sans que les développeurs s'en soucient de trop (merci aux goroutines, à la sobriété de son runtime et à la simplicité de configuration son garbage collector).
Là, j'ai l'impression, peut-être à tort, qu'on parle plus de d’algorithme dont la limite sera plus la puissance de calcule (CPU bound) avec des gros volumes de données qui n'est pas pour moi le cœur de la cible de Go.
[^] # Re: https://killedbygoogle.com/
Posté par woffer 🐧 (site web personnel) . En réponse au journal Google forke C++. Évalué à 8.
Je ne pense pas que le Go et le C++ jouent dans la même cours.
Go ne sera jamais rapide comme le C/C++/Rust/(ajouter ici le langage de votre choix).
Pour moi, le Go brille dans les domaines où les applications passent la majorité de leurs temps à attendre les entrées/sorties (I/O bound) et dans des environnements d’exécution contraints (i.e. tournant sur des pods avec 50 millicpu & 50 mo de ram parce que ça coûte moins cher chez AWS/GCP/Azur/on-premise/(ajouter ici le cloud provider de votre choix). Dans ce domaines, Go permet très facilement de gérer ce genre de problèmes sans que les développeurs s'en soucient de trop (merci aux goroutines, à la sobriété de son runtime et à la simplicité de configuration son garbage collector).
Là, j'ai l'impression, peut-être à tort, qu'on parle plus de d’algorithme dont la limite sera plus la puissance de calcule (CPU bound) avec des gros volumes de données qui n'est pas pour moi le cœur de la cible de Go.