Go : avenir et domaines d'applications ?

Salut à tous !

Je me pose une question concernant Go -langage que j’apprécie et utilise pour des projets personnels- : à quel type de projets est-il destiné ?

Quels langages sont voués à être progressivement remplacés par Go ? (Aucun ?)

Il était originellement annoncé comme orienté système, mais semble aujourd’hui ce concentrer davantage vers du web. Personnellement, je le vois peut-être comme remplaçant de Node, en apportant les avantages d’un langage compilé et statiquement typé.

Et vous, qu’en pensez-vous ?

Salut,

Je fais aussi du Go depuis quelque temps.

Je ne sais pas si le Go à pour futur de remplacer un langage.
Je dirais plutôt qu’il à vocation à être dans les applications qui tournent dans le cloud, parce qu’il à des temps de compilation et d’exécution très raisonnable (qui est un gros avantage quand tu paye ton cloud à l’utilisation).

Je ne sais pas si il s’oriente vraiment vers du web, cependant il répond de manière très simples à la plupart des problèmes (dont les petits service web). Il permet de faire vite et simplement les choses je trouve.

Merci pour vos réponses !

Il permet de faire vite et simplement les choses je trouve.

C’est en effet l’un des plus gros points forts du langage ; tu peux arriver très rapidement à quelque chose de viable.

[…] je dirais qu’il joue surtout dans la même cour que C# et Java

Je ne sais pas si aujourd’hui -en l’absence des generics- il peut être comparé à C# ou Java. Utilisant C# tous les jours au boulot, il y a (entre autres) certains aspects de programmation générique que je pourrais difficilement reproduire en Go.

Ca n’est que mon avis, mais je ne suis pas sûr que l’on puisse aujourd’hui réaliser en Go des applications avec tout le confort offert par C#.

les generics pourraient nous aider à écrire des structures de données qui soulagent le Garbage Collector dans les portions critiques du code

Intéressant ! Tu pourrais détailler ce point ?

[…] je dirais qu’il joue surtout dans la même cour que C# et Java

Je ne sais pas si aujourd’hui -en l’absence des generics- il peut être comparé à C# ou Java. Utilisant C# tous les jours au boulot, il y a (entre autres) certains aspects de programmation générique que je pourrais difficilement reproduire en Go.

Ca n’est que mon avis, mais je ne suis pas sûr que l’on puisse aujourd’hui réaliser en Go des applications avec tout le confort offert par C#.

Mon expérience perso, c’est qu’en un an à bosser sur des trucs plutôt pointus en Go (genre des extensions et des contrôleurs custom pour Kubernetes, donc pas le genre de trucs que fait M. ToutLeMonde), je n’ai jamais ressenti le manque de generics au travail. La seule fois où j’en ai eu l’utilité, c’était pour un exo particulier de l’Advent of Code en décembre.

Du coup mon point de vue sur la question c’est que l’absence (pour quelques mois encore) des generics est un "faux problème", dans le sens où il n’est pas si significatif qu’on pourrait le croire : dans la culture de Go, on préfère écrire des programmes qui génèrent automatiquement du code simple et rajouter cette étape à la compilation, plutôt que d’écrire immédiatement des templates compliqués, et à mes yeux les generics vont surtout permettre de s’affranchir de la génération de code dans les cas limites (par exemple, pour avoir une bibliothèque de maths digne de ce nom avec des fonctions math.Abs ou math.Max qu’on n’a pas besoin de récrire à chaque fois).

De même, le confort en Go ne vient pas de l’expressivité du langage, mais au contraire, de sa simplicité : il est encore plus pythonique que Python dans le sens où il y a vraiment une façon et une seule de faire chaque chose (on n’a pas 25 façons différentes de formater une chaîne de caractères… regard en biais lourd de sens sur Python 3.6). Par exemple, quand on ouvre le capot de Kubernetes (qui est un mastodonte) pour regarder comment c’est foutu, le code est vraiment facile à suivre, et tout aussi simple à étendre. Je demande à voir une codebase en Java ou en C# de la taille de Kubernetes dans laquelle il soit aussi facile de rentrer (quand on ne l’a pas codé) pour trouver les réponses à des questions précises du style "quand un pod est créé à partir d’un Deployment, celui-ci est annoté avec le hash de son template : comment est calculé ce hash exactement ?".

Autrement dit, il n’est tant pas là pour qu’on puisse se pâmer quand on écrit notre code pour la première fois, que pour que les N personnes qui reliront ce code dans les 5 ans à venir n’éprouvent aucune difficulté à le comprendre, le débugger et le faire évoluer.

Par contre, si je dis que l’arrivée des generics risque de bouleverser Go, c’est justement parce que des tas de gens attendent ces generics pour le considérer/se mettre à l’utiliser (ce que je trouve très dommage, mais on s’en fout, il ne reste plus que 6 mois).

Ce qui fait le plus mal en l’absence de generics, c’est qu’on ne peut pas écrire des structures de données comme des conteneurs qui sont réutilisables. Au mieux, si tu veux une Deque à l’heure actuelle, tu es obligé de représenter ses éléments par une interface{}, ou bien par le type très précis dont tu as besoin pour ne pas perdre le typage et éviter de te taper des type switches, au risque de devoir recoder ta Deque avec un autre type plus tard. Dans ces conditions, on n’a pas encore de bibliothèque performante qui modélise des collections génériques en limitant les allocations dynamiques, comme la STL de C++.

Je pense que c’est la principale barrière qui nous empêche de créer un moteur de jeu digne de ce nom en Go.

Du coup mon point de vue sur la question c’est que l’absence (pour quelques mois encore) des generics est un "faux problème", dans le sens où il n’est pas si significatif qu’on pourrait le croire : dans la culture de Go, on préfère écrire des programmes qui génèrent automatiquement du code simple et rajouter cette étape à la compilation, plutôt que d’écrire immédiatement des templates compliqués, et à mes yeux les generics vont surtout permettre de s’affranchir de la génération de code dans les cas limites (par exemple, pour avoir une bibliothèque de maths digne de ce nom avec des fonctions math.Abs ou math.Max qu’on n’a pas besoin de récrire à chaque fois).

C’est peut être pas un besoin dans ta niche d’utilisation, c’est une nécessité dans la mienne. Je fais de la simulation numérique, principalement de la mécanique des fluides. Il se trouve que je suis dans la recherche, mais les méthodes sont les même dans l’industrie des maths appliquées qui est énorme (on fait pas d’avions, d’ordinateurs, de médicaments, de technologie en général sans ça aujourd’hui).

On est bloqué avec Fortran pour des raisons historiques, et c’est une horreur. On peut critiquer beaucoup de choses en Fortran, mais le vrai problème de fond pour notre application, c’est que Fortran n’offre que des moyens très limités de faire du code générique. Généraliser des opérations toute bêtes du genre "je veux interpoler tel champ sur telle grille" ou "je veux le gradient de ce champ" devient plus compliqué que dupliquer du code. Donc on duplique du code à la pelle, mais invariablement les interpolations ou les discrétisations d’opérateurs différentiels vont être faux quelque part dans le code. Si on peut encoder certains choses (comme où un champ est connu, si c’est un vecteur ou un scalaire) dans le système de type et écrire du code générique par dessus, on évite toute une classe de bugs, on simplifie le code, et on le rend plus flexible. Je pourrais même voir des utilisations possibles pour les HKT, et leur intégration dans Rust sera un bon en avant utile (on les verra probablement pas en Go par contre). Utiliser des génériques en les forçant là où ils ne sont pas nécessaires, c’est sûr que c’est pas intelligent. Mais il y a des cas où l’utilisation est plus que légitime et carrément centrale, et c’est exactement ce qui rend Go inutilisable pour moi sans générique. Le code serait à peine plus propre que ce qu’on écrit en Fortran aujourd’hui. Il serait pourtant un excellent remplaçant à Python pour nos applications de post-processing (et Rust serait parfait pour les calculs eux-mêmes où les perf sont capitales). J’imagine qu’il y a des tas d’autres cas dans l’industrie en dehors de ton cas (qui comme tu le dis est particulier) où les génériques ne sont pas du luxe mais un vrai besoin. Leur absence dans Go est un réel frein à son adoption. Tout ça pour dire que les génériques ne sont pas une lubie d’académiciens dans leur tour d’ivoire qui se "pâment" devant leur code.

C’est peut être pas un besoin dans ta niche d’utilisation, c’est une nécessité dans la mienne.

Je n’ai pas de Go qu’une utilisation de niche, je développe aussi tout un backend avec. Mon métier n’est pas particulier : ce qui est particulier, c’est certains des trucs que j’ai été amené à toucher, mais mon métier consiste aussi, pour une grosse part, à faire "des trucs comme tout le monde dans ce domaine" : des API et des services de backend, pour lesquels, là non plus, les generics n’ont rien de transcendant à apporter.

Du coup je pense que je peux avancer sans trop me montrer présomptueux que l’absence des generics de Go est un faux problème dans son principal domaine d’application qui s’avère être mon métier, et pas seulement "dans mon cas perso".

Qu’il ne soit pas adapté pour faire de la simulation numérique, ça je veux bien le croire. Ce n’est juste pas pour ça qu’il a été créé originellement, ni (d’après le sondage annuel de la communauté) ce que la plupart de ses utilisateurs attendent de lui.

Pour le reste je ne commenterai pas cette histoire de "lubie d’académiciens", je n’ai jamais dit ni même pensé un truc pareil. Je n’imaginais pas que mon utilisation du verbe se pâmer puisse provoquer un tel émoi.

Edit : d’ailleurs il semblerait que l’intégration des generics ait été reprogrammée plutôt pour la 1.18. Mon info 1.17 venait de l’état du draft en décembre 2020.

En fait, avec mon message, je voulais surtout enfoncer le clou sur deux aspects :

Par contre, si je dis que l’arrivée des generics risque de bouleverser Go, c’est justement parce que des tas de gens attendent ces generics pour le considérer/se mettre à l’utiliser (ce que je trouve très dommage, mais on s’en fout, il ne reste plus que 6 mois).

C’est pas dommage, c’est un vrai frein. Que la base d’utilisateurs existante n’en ait pas un besoin critique, c’est une chose, mais je voulais surtout souligner que les génériques répondent à des besoins industriels qui vont plus loin que ce que ton message pouvait laisser penser.

Du coup mon point de vue sur la question c’est que l’absence (pour quelques mois encore) des generics est un "faux problème", dans le sens où il n’est pas si significatif qu’on pourrait le croire

Ou bien il est plus significatif en général que ce que tu vois dans ton domaine d’application. Forcément, si on se base sur ce que font les utilisateurs actuels avec le langage, on ne peut pas voir ce qui limite une adoption plus large du langage (ce qui fait quand même partie de ce sujet, il me semble).

Je n’imaginais pas que mon utilisation du verbe se pâmer puisse provoquer un tel émoi.

C’est surtout que certain détracteurs des systèmes de types un peu abstraits disent que ça sert à rien dans la vraie vie™ et que c’est bon pour amuser les matheux dans leur coin. J’ai sur-interprété tes propos dans cette direction.

Il faut distinguer "une adoption par plus d’utilisateurs", de "une adoption dans des domaines plus variés".

En ce qui me concerne, je me moque un peu que le langage s’ouvre à d’autres domaines, du moment qu’il reste simple, cohérent et qu’il ne perde aucune des qualités pour lesquelles je l’utilise aujourd’hui dans le mien.

Je vois l’arrivée des generics (qu’on peut déjà essayer, au passage) d’un bon oeil, parce que je pense qu’ils vont effectivement apporter quelque chose de positif au langage, mais en ce qui me concerne toujours, je pense que quand on envisage à l’heure actuelle d’utiliser Go, c’est généralement qu’on a un projet qui tombe dans ses cordes, à savoir, le plus souvent, qui tombe dans un domaine où on peut très bien s’en passer sans que ce soit un handicap.

Qu’il existe d’autres domaines dans lesquels les gens attendent les generics de Go pour l’adopter, je l’entends et le comprends très bien, et tant mieux pour eux puisqu’ils arrivent. Et tant mieux pour tout le monde parce qu’à l’heure actuelle ils me donnent l’impression d’enrichir le langage plus qu’ils ne le complexifient.

PS :

C’est surtout que certain détracteurs des systèmes de types un peu abstraits disent que ça sert à rien dans la vraie vie™ et que c’est bon pour amuser les matheux dans leur coin. J’ai sur-interprété tes propos dans cette direction.

Ah non, je ne suis pas détracteur des systèmes de types à la Rust, au contraire, j’aime beaucoup Rust. J’ai sur la question un point de vue beaucoup plus pragmatique : qu’est-ce que ça me coûte vs. qu’est-ce que je gagne par rapport à ma situation actuelle. Je vois des cas où la balance penche dans un sens, d’autres dans l’autre, et le mien actuel est du côté "ça vaut moins le coup que Go".

Bonjour à tous,

Go m’a beaucoup plu, mais en absence de bibliothèque graphique je me suis intéressé à la bibliothèque Fyne où je me suis arraché les cheveux pour arriver à avoir une fenêtre Windows construite en Go.

Mauvaises explications et mauvais téléchargements. J’ai réussi avec MSYS2.MSYS et pas avec MinGW64, un comble ! Avec MinGW64, à la compilation , GO ne trouvait pas GCC malgré mes variables d’environnement bien renseignées. J’ai été très énervé car cela doit rouler et vite.

De plus MingGW64 est une une daube où il faut cliquer sur des milliers de packages pour les installer et idem pour les désinstaller, pas d’uninstall, nul !

Bref en restant zen j’ai installé MSYS2.MSYS en suivant scrupuleusement la doc, et là ça marche !

Je suis un vieux de la vieille , je pense que la prochaine fois si je dois avoir affaire à de tels problèmes pour un nouveau langage, je laisserai tomber.

Ce n’est pas normal d’avoir de la doc inefficace avec cette perte de temps.

Maintenant j’ai une belle fenêtre Windows avec widgets mais quasiment aucun tuto.

Il faut en vouloir pour faire du GO sachant que j’ai mis en stand by Rust particulièrement imbuvable, notamment sur les Strings.

Bonne soirée à tous.

Re Bonsoir à tous,

Je connais de loin GCC (le compilateur), quelqu’un peut il m’expliquer que ayant installer GO en ayant au préalable installé les outils de compilation C et C++ pourquoi Fyne a besoin de GCC et de CC1, je me coucherais moins idiot si quelqu’un me répond.

Re Bonne soirée

Salut,

@Jack : si tu as des questions sur l’utilisation de Fyne, il serait de bon ton de les poser dans ton propre sujet. Maintenant, pour répondre à ta question, la réponse est sur la page d’installation de Fyne

Fyne requires […] a C compiler (to connect with system graphics drivers)

Comme Go n’est pas un langage système, s’interfacer avec des lib est plus facile en écrivant une petite couche de C pour faire le pont entre les lib de bas niveau et Go. En allant voir le code, on trouve par exemple ce genre de chose pour faire le pont avec X11, ou bien celui-là pour faire le pont avec Android. Il y aussi d’autre petits bouts de C qui sont des dépendances en C que Fyne embarque directement.

Coucou adri1,

Merci de ta réponse,

Je me suis mal exprimé, en installant Fyne (écrit en Go je crois) et étant sous Windows 10 je me posais la question pourquoi cette bibliothèque (bien que ce n’est pas toujours le cas mais j’ai vu des bibliothèques détecter l’OS) ne détecte pas l’OS et nous insulte avec CC1 et GCC, (si c’est via MinGW64) alors que MSYS264 bits , nickel,ce devrait être simple et transparent alors que le compilateur C est présent (et CC1 et GCC aussi).

Je veux dire "Tu es sur Windows 10, pas besoin de CC1 et GCC, mais je rêve sans doute"

Bon , j’ai bien compris les ponts nécessaires qu’apporte sans doute la liaison ce qui invalide sans doute ma phrase précédente.

"Fyne, il serait de bon ton de les poser dans ton propre sujet"

D’accord mais je pouvais toute même poser des questions en relation avec Go, d’autant que Fyne serait développée en Go

Je n’ai pas encore vu tes liens que je vais explorer.

Merci encore à toi de m’avoir répondu.

PS : 1/ Tu ne me dis pas pourquoi MingGW64 ne fonctionne pas. 2/ J’ai mis Rust en stand by, courbe d’apprentissage très rude, mais c’est bon pour les méninges, et pareil , graphisme, hello les bibliothèques.

adri1,

Désolé de mal m’exprimer encore, je sais que GCC et CC1 compilent du C, mais pourquoi exiger GCC et CC1. J’avais résolu le tout (installation de MSYS2.MSYS) en resuivant le lien Fyne que j’avais exploré avant que tu me le fournisse.

J’ai compris malgré tout, étant un peu bête que Fyne veut GCC et CC1, avoue tout de même que c’est pas cool.

Moi j’aime que çà roule, ayant fait du Basic, Forth (plus personne ne connait) C, C++, Perl, Cobol, Java, C#, je me dis parfois que l’open source est un peu usine à gaz, détrompe moi.

J’ai connu le développement des langages depuis 1984 et je suis toujours sur le c.l de voir toutes ces nouveautés qui sont quand même intéressantes comme Go et Rust. Bon le truc bien et pas bien en go c’est le "unused" qui perturbe pour les variables ou les bibliothèques non utilisées (qui interdit toute compilation, ils ont copié Rust) mais on s’y fait.

J’aime bien le paradigme de Go, comme Rust, après il faut s’y faire, Rust dur à apprendre me plait car il interdit toute erreur de mémoire ou de variable avant la compilation, mais dur dur..

Bonne nuit

Merci de créer un sujet propre pour poser vos questions et de ne pas déterrer des sujets anciens.