Golang, débat

a marqué ce sujet comme résolu.
Banni

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 : image.png

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

Merci

Tu n’as toujours pas répondu à ma question :

Tu peux définir "bon langage" ?

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.

DonKnacki

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.

Aucune gestion des erreurs

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.

Banni

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).

Argument d’autorité

CactusCata

Donc tu ignores mon discours sous prétexte que… j’ai de l’expérience ?

À part être de mauvaise fois, je ne vois pas ce que tu cherches à montrer ici.

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

CactusCata

Laisse-moi te faire découvrir un truc merveilleux : il existe d’autres gens.

+0 -0
Banni

Tu l’as dis toi même, tu as 15 ans d’expériences en JS & PHP. On est loin de Go et de Rust

Laisse-moi te faire découvrir un truc merveilleux : il existe d’autres gens.

Il existe des gens stupide qui ont besoin d’un langage comme Go ?

Je n’aime pas cette vision. Tout le monde est intelligent

+0 -7
Banni

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.

+2 -0
Banni

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

+0 -8
Ce sujet est verrouillé.