Je voudrais faire un débat sur Go par ce que je ne comprend pas l’intérêt du langage, il ne propose pas de gestion d’erreur, de nulls, il a des pointeurs mais un ramasse miette
Son créateur semble ne pas l’aimer non plus :
Derrière, des articles liste bien les problème du langage comme lui
Je souhaite avoir des retours d’utilisateur de Go pour m’expliquer en quoi c’est un bon langage
Vu que tu pars avec un avis visiblement très tranché il va falloir nous donner une idée des arguments que tu attends, sinon on considérera que tu cherches juste à troller, ce qui ne rendra service à personne.
Un langage est un outil conçu dans un but précis. Aucun langage n’est parfait non plus (je suis bien placé pour le savoir, je fais du PHP et du JS depuis 15 ans).
À partir de là, tu ne vois peut-être pas l’intérêt pour ton contexte, mais tant que ça rend service à quelqu’un on s’en fiche un peu, non ?
Pour moi, le fait d’avoir un langage facile à comprendre et facile à prendre en main le rend assez "brillant" non ?
En tout cas, les langages les plus récents ont tendance à suivre cette ligne de conduite.
Pour moi, le fait d’avoir un langage facile à comprendre et facile à prendre en main le rend assez "brillant" non ?
En tout cas, les langages les plus récents ont tendance à suivre cette ligne de conduite.
Plus exactement, je dirais que les langages « modernes » cherchent à être expressifs et à permettre aux développeurs de se développer sur ce qui fait sa valeur ajoutée, à savoir : écrire du code « métier ». Différentes catégories de langages correspondent à différents types de métier différent. Ça implique d’abord d’avoir un langage adapté à ce qu’on veut faire (audit métier, donc), qui dans ce cadre limite tout ce qui est boilerplate et baston contre le langage lui-même.
Ça peut impliquer d’avoir un langage facile à comprendre et à prendre en main, mais pas toujours : si le métier implique de manipuler des concepts complexes (par exemple des choses proches de la machine), il faudra toujours les gérer. Je pense à des exemples comme rust, là.
De même, Kotlin vise l’expressivité et une forme de concision, la facilité à comprendre et à prendre en main venant de plus en plus en second plan, même si ça reste une caractéristique importante du langage (amusez-vous avec les coroutines par exemple, de même certaines structures du langage peuvent vite assez cryptiques).
Une conséquence de cette approche pragmatique, c’est qu’on a tendance à s’éloigner des concepts « propres » édictés par la recherche, parce que la pratique montre que ces concepts, intéressants en théorie, mais assez peu utiles en pratique – ce qui fait hurler certains partisans de la recherche en théories des langages.
Une autre approche, c’est que ça conduit à des langages relativement spécialisés en fonction de ce qu’on veut faire. On aura pas les mêmes besoins pour faire de la programmation très bas niveau, du calcul haute performances, des modules de sûreté (cryptographie, etc) pour lesquels la tolérance aux failles est bien plus importante que la performance, du code semi-jetable pour des applications (au sens large) temporaire, du code très évolutif pour répondre à un besoin très mouvant, du code qui doit rester en production à l’identique pendant des années sans vraie possibilité de mise à jour, etc.
Enfin, le classement dans l’article mentionné dans le premier post me fait penser à ces vieilles discussions sur « Le programmeur moderne » puis « Prog du peuple » où des intervenants ne juraient que par les langages fonctionnels et les aspects de beauté théorique, en oubliant souvent que ces contrainte sont souvent éloignées de celles de l’industrie. Laquelle a, en effet, un certain nombre de besoins où « pouvoir rentrer facilement dans le code sans être expert » est un réel plus. En ceci, considérer que le programmeur qui va utiliser le programme n’est pas spécialement bon peut être un vrai critère de conception du langage.
PS : d’autant plus que le classement ne parle pas des versions du langage. Par exemple, Java 6 n’a pas grand-chose à voir avec Java 8 qui est lui-même différent de Java 17. L’écosystème a beaucoup évolué aussi. De même, JavaScript aujourd’hui n’a rien à voir avec ce qu’il était il y a 10 ans, tout comme PHP, et sans doute bien d’autres.
Alors, ça fait plus d’une année que je travail avec Go professionnellement, je trouve que c’est le langage qui jusqu’à présent gère le mieux les erreurs (bien mieux que les langages comme C# et Java avec leur try/catch.)
Ça évite les codes legacy ou j’ai un try catch englobant plus de 4000 lignes de codes, indebuggable.
Pointeur alors que GC
La aussi, je ne vois fondamentalement pas le problème. Les objets sont supprimé par le GC du moment où il n’y a plus aucune référence vers le pointeur.. je n’ai a priori jamais eu de soucis de fuite de mémoire.
———
Je pense qu’avant de venir simplement bâcher un langage sur 3 petits points discutables, il faudrait un minimum s’y intéressé et voir ce qu’il propose.
Un langage est un outil conçu dans un but précis. Aucun langage n’est parfait non plus (je suis bien placé pour le savoir, je fais du PHP et du JS depuis 15 ans).
Argument d’autorité
Pour moi, le fait d’avoir un langage facile à comprendre et facile à prendre en main le rend assez "brillant" non ?
Rust est loin d’être facile à comprendre et facile à prendre en main et c’est un langage brillant
Outre passer 15 ans de recherche de langage, pas sûr que ça soit la meilleure des choses
La aussi, je ne vois fondamentalement pas le problème. Les objets sont supprimé par le GC du moment où il n’y a plus aucune référence vers le pointeur.. je n’ai a priori jamais eu de soucis de fuite de mémoire.
Justement, à quoi sert un pointeur si y’a un GC derrière, c’est un no-sense qui rajoute de la complexité pour rien
Je n’aime pas qu’un langage soit créer en supposant que je ne suis pas assez brillant pour comprendre C++ & Rust
Un langage est un outil conçu dans un but précis. Aucun langage n’est parfait non plus (je suis bien placé pour le savoir, je fais du PHP et du JS depuis 15 ans).
Un langage est un outil conçu dans un but précis. Aucun langage n’est parfait non plus (je suis bien placé pour le savoir, je fais du PHP et du JS depuis 15 ans).
Argument d’autorité
Non, c’est plus un exemple d’expérience personnelle.
Pour moi, le fait d’avoir un langage facile à comprendre et facile à prendre en main le rend assez "brillant" non ?
Rust est loin d’être facile à comprendre et facile à prendre en main et c’est un langage brillant
C’est cool, on n’a jamais dit le contraire.
Je n’aime pas qu’un langage soit créer en supposant que je ne suis pas assez brillant pour comprendre C++ & Rust
Ça doit sûrement être pour ça que je peux pas blairer de toucher à du Rust ou du C++ : parce que ce sont des langages fait pour moi, mais que je dois être le seul type trop stupide dans ce monde.
Faire du Rust ou du C++ n’est pas réservé à une élite. Vouloir faire un langage pour pouvoir je cite : "utiliser les gens qui ne sont pas capable de comprendre un langage brillant" est selon moi très limite
On résume la phrase à : "Ils sont trop bêtes pour utiliser un vrai bon langage mais on veut les utiliser quand même"
Je pose la question : as-tu vu et lu la réponse de @SpaceFox plus haut ? Car elle répond à a peu près tous les points que tu remets en cause en ajoutant pas mal de nuance — ce qui manque beaucoup à tes propos, je trouve, et c’est bien dommage.
Personne ici n’utilise Go de manière pro… donc les avis sont des suppositions selon moi
Pour information, le seul truc bien en go est que nimporte qui peut en faire en 2 jour mais se rabaisser à utiliser un langage comme ca, c’est ne pas aimer son travail
