Que pensez-vous de ce nouveau langage ?

Et de ses frameworks Web ?

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous,

Je me permet d'ouvrir ce topic sur le langage Go (diminutif de Golang).
En effet, certains d'entre vous ont pu en entendre parler.
Pour résumé, le langage Go a été créé par 3 ingénieurs de Google. Ils se sont inspirés de C et de Pascal sauf que la compilation du code est de 80 à 90% supérieure à celle de C !

Go étant un langage relativement jeune (sorti fin 2009), on ne trouve hélas pas beaucoup de tutoriels en français. Je voulais savoir si un (big) tuto était en cours de rédaction ?

Étant plus orienté dans le développement web, j'ai commencé à tester un framework web basé sur Go qui se nomme Revel (http://revel.github.io) mais il en existe d'autres.
La documentation est bien documentée sauf pour connecter une base MySQL (ou autre) à son application :(

Un retour intéressant trouvé sur le net :
http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html

Benchmarking :
- http://www.techempower.com/benchmarks
- https://jaxbot.me/articles/node-vs-go-2014
- https://plus.google.com/+MattAimonetti/posts/PeZk8FY3PWY (le dev a utilisé Revel pour l'API sur Go)

Ce topic n'a pas pour but de promouvoir, ni de faire l'éloge de ce langage mais simplement de recueillir vos avis ou vos retours d'expériences.

HTTP/1.1 418 I'm a teapot

+0 -0

Ça fait 5 ans que Go est dans les bacs, il n'est plus trop « nouveau » maintenant ;p. La vitesse de compilation du Go est peut-être 80% à 90% supérieure à celle du C, mais rien de plus. Le temps d'exécution est encore bien en deçà si tu utilises leur compilateur. Il s'améliore si tu utilises le front end GCC, cependant… Mais tout n'est pas compatible avec ce front end il me semble, notamment cgo (mais il faudrait vérifier).

J'ai utilisé le Go pour divers projets personnels. Le langage est agréable à utiliser, ça ne fait aucun doute. J'aime le côté « objet dégraissé, léger ». Pour ceux qui ne connaissent pas, dans Go, on n'a pas de classes, d'héritage, etc. On a des structures auxquelles on peut attacher des méthodes et des interfaces (un ensemble de méthodes à implémenter).

Je regrette cependant l'absence de generics/templates qui forcent à utiliser le type interface{} (ce qui est laid). Ou la pauvreté de l'écosystème, notamment niveau interface graphique, ça ne se bouscule pas des masses (mais en même temps, le langage n'est pas spécialement fait pour ce genre d'utilisation).

Ça n'empêche pas Go d'avoir trouvé son public. Docker, par exemple, est écrit en Go.

J'ai essayé revel et beego et mon choix ce porte clairement sur beego.

Documentation bien faite avec des exemples concrets la possibilité de spawn un projet api ou appli web est super pratique. Le générateur de documentation est aussi un bon petit plus. Enfin la couche orm est bien foutu et rappelle du doctrine

Edit : Niveau bench aussi beego est plus perf.

Édité par adrii

+0 -0

J'ai jamais réussi à me mettre à Go. Ca semble être un langage vraiment sympa, de belles promesses et tout mais ça reste limité à des projets persos. Je n'ai jamais rencontré une entreprise qui développait en Go.

Par contre, niveau ressource, tu en as pas mal. Personnellement, j'aime beaucoup le tuto step-by-step sur le site officiel et le cours français sur la documentation de golang-france. Si ça peut aider. :)

+0 -0
Staff

Je pense que les futurs langages de programmation qui trouveront un public assez large auront un aspect sécurité assez élevé comme le typage statique fort (voir la news sur Ceylon).

Malheureusement, je pense que Go ne propose pas de concepts assez novateurs par rapport au C ou au C++ (voir d'autres langages) pour qu'il soit utilisé massivement.

Beaucoup de gens utilisent C/C++ pour leur rapidité et non pour la beauté du langage. Si Go ne peut pas concurrencer à ce niveau, il faut qu'il vise un autre marché mais lequel ? Pourquoi un développeur avec des années d'expériences dans des langages qui ont fait leurs preuves, souhaiterait devenir expert en Go ? La vitesse de compilation est bien un argument rédhibitoire surtout qu'il existe des outils pour compiler au fur et à mesure que l'on écrit du code.

+0 -0

D'ailleurs, je rebondis rapidemment, y a t il des langages veritablement novateurs? Qui sorte de la conception objet par exemple, qui se pencherait plus sur du multithreading (=> le modele Entity Component par exemple)

+0 -0

D'ailleurs, je rebondis rapidemment, y a t il des langages véritablement novateurs?

Bon, ça fait un peu fan boy, mais Julia ?

Le grand apport est pour moi le dispatch multiple, et le langage intègre aussi des bouts de méta-programmation plutôt bien faite. Pour ceux qui veulent comprendre le dispatch multiple et la distinction fonction/méthode, regardez à partir de la diapo 9 ici.

Mon Github — Tuto Homebrew — Article Julia

+0 -0
Staff

Ben il y a la programmation par aspect que je connais juste de nom qui demande juste à se faire connaître. Après je sais qu'il y a des trucs vraiment sioux qui existent sur des très jeunes langages, malheureusement, je ne me souviens plus des noms de ces langages…

+0 -0

@Luthaf: Le multiple dispatch et la méta prog' ça n'a rien de nouveau. CL le fait déjà très bien. Par contre oui, c'est une approche intéressante.

Sinon concernant le langage Go, j'ai regardé vite fait mais sans plus : je lui préfère Erlang même si c'est assez particulier.

+0 -0

Le langage Go a l'air intéressant, mais il a à mon sens deux défauts.

  1. C'est une création de Google, qu'ils semblent vouloir imposer comme standard de fait à la place de Javascript, et je suis toujours très circonspect vis-à-vis des "cadeaux" que Google fait au monde.
  2. Si Go est plus rapide à compiler que du C, c'est en grande partie parce qu'il est beaucoup plus pauvre en fonctionnalités. C'est une spécialité de Google : ils ont créé Chrome en concurrence avec Firefox et ont fait beaucoup de pub autour des perfs de leur bébête… en omettant de préciser que, pour arriver à ce résultat, ils ont dû supprimer des dizaines de fonctionnalités que propose leur concurrent.

Et pour répondre à Riccocotam, pour tout ce qui n'est pas critique au niveau des perfs (là, rien ne peut remplacer le C + ASM), j'aime beaucoup Haskell et son paradigme de pensée très différent, même si on ne peut plus vraiment le qualifier de novateur.

#JeSuisGrimur #OnVautMieuxQueÇa

+3 -5

Ben il y a la programmation par aspect que je connais juste de nom qui demande juste à se faire connaître.

Saroupille

Elle est déjà très bien connue en réalité. Mais ne "suffit" pas pour constituer un langage.

Si tu as déjà utilisé les décorateurs en Python, tu as fait de l'AOP en fait.

C'est une approche complémentaire dont on peut fortement avoir besoin dans une grosse application. Définir un point de coupe pour dire "tout ce qui passe par ici doit faire ça" c'est intéressant quand tu as déjà un programme qui tourne, mais pas pour architecturer un projet.

J'ai du mal à concevoir l'AOP comme un paradigme à part entière. Pour moi c'est comme regarder une maison sous un autre angle. Elle est là, construite, mais tu l'inspectes d'une autre façon.

Happiness is a warm puppy

+0 -0

Selon moi, Go est un mauvais langage pour plusieurs raisons que je vais décrire ici.

Programmation générique

En effet, une des premières critiques de Go est la programmation générique. Les développeurs du langage étaient contre les génériques au début ne voulant pas compliquer le langage de manière significatif. La programmation générique est possible dans les langages avec un typage dynamique comme Python mais ce dernier rajoute un overlay au runtime (pour savoir qu'elle type on manipule) - ce papier de recherche montre l'implémentation d'un typage dynamique dans OCaml et parle de se qu'on nomme le polymorphisme ad-hoc.

Mais ce genre de système n'a pas était retenu par les développeurs de Go (et d'OCaml d'ailleurs). Cependant, avec un système de type bien pensé, le polymorphisme est tout autant possible (OCaml le prouve tout les jours avec ses foncteurs). On pourrait se rabattre aux templates ce qui rajouterait par la même occasion la méta-programmation mais il me semble que ce dernier est le principal facteur du temps de compilation du C++ qui reste le lance de guerre (à défaut d'en avoir d'autre) de Go.

Alors qu'on se le dise bien, le système de type de Go reste médiocre par rapport à ses compères tel que OCaml et Haskell. Et on voit donc l'apparition de interface{}. C'est typiquement ce que je critique à pas mal de langage informatique qui est celui de suivre son intuition pour répondre à une problématique à l'aide de rustines - ce qui n'est jamais bon pour un langage. C'est un peu l'équivalent d'Obj.magic en OCaml qui permet de by-passer tout le système de type pour avoir un void* ce qui reste en contradiction avec le système de typage fort puisque désormais, interface{} rajoute un type Top (cf. TAPL) ou Object (cf. Java) - on pourrait dire la même chose d'OCaml avec Obj.magic mais:

Obj.magic is not part of the OCaml language

Et l'utilisation de interface{} semble être la norme pour les utilisateurs de Go.

Surcharge

C'est un problème similaire à OCaml avec l'opérateur +. et les flottants. Cependant, les développeurs essayent de trouver une solution tout en restant conforme avec le système de type existant. Les développeurs de Go ont raison de faire attention sur ce point qui peut être la source de pas mal de bug si c'est couplé avec un système de typage faible et, développant avec OCaml tout les jours, cela resterait occasionnellement efficace AMHA.

Du côté d'OCaml, la solution reste la redéfinition des fonctions pour le type attendu. Et nous pouvons faire ceci pour l'instant:

1
2
module Float = struct let ( + ) = ( +. ) end
Float.(4.0 + 2.0)

Je ne pense pas qu'il y est d'équivalent en Go. Cependant, cela reste une vraie question. Avons nous réellement besoin de la surcharge ? En C++, dès que le code-base devient important, la surcharge peut être un vrai problème puisque, même si le compilateur trouve la bonne fonction/le bonne opérateur, ce n'est pas forcément le cas du développeur.

Le pointeur Nil

L'histoire nous a montré qu'il fallait minimiser l'existence du NULL comme c'est le cas en C++ ou dans des langages plus haut niveau comme Python, Ruby, OCaml, Haskell, etc. Je pense que Go pouvait se permettre de réduire son existence à néant même si il devait y avoir un overlay sur les fonctions disponibles dans la LibC (OCaml y est parvenu) - le Nil casse tout autant le système de type fort aussi.

Immutabilité

Il faut parfois offrir les outils nécessaire afin d'empêcher le programmeur à faire des erreurs. L'immutabilité est une solution permettant de mieux localiser les erreurs dans le code et permet d'offrir des assertions intéressantes et ainsi confiner les effets de bords au mieux possible. Swift et JavaScript plus récemment ont offert cette possibilité, elle est bien plus fondamentale dans les langages tel qu'OCaml ou plus extrême dans Haskell.

Je considère qu'un langage qui se veut être safe devrait pouvoir offrir ce genre d'outil. Rob Pike disait à ce sujet que le développeur pouvait transgresser ce genre de contrainte si vous avez le choix de faire quelque chose de plus efficace et si vous savez ce que vous faites (on peut imaginer qu'il fait mention au const_cast de C++). Je pense surtout qu'il y a un problème de cible ici, Go a voulu s'imposer à l'époque comme un remplaçant du C++ et du C ce qui a échoué vu l'état de la communauté et de ses objectifs qui sont différents des développeurs C et C++ - cela ne veut pas dire que Go n'a pas sa place dans le paysage des langages informatiques, mais qu'il s'est trompé de place.

Système embarqué

La première critique et la plus fondamentale est l'utilisation d'un garbage collector. La programmation dans des systèmes embarquées consiste à de la programmation dans des environnements hostiles dans lequel la latence est facteur à prendre réellement au sérieux. L'allocation dans le tas (qui est quasi le cas en Go) doit être utilisé à bon escient. C'est le cas par exemple dans Rust qui offre les outils nécessaires pour limiter l'utilisation du tas d'allocation.

Go n'a pas fait ce choix et forcément, c'est un langage qui ne correspond pas à cette classe de problème qui demande une gestion en temps réel (il ne devrait y avoir aucune latence, mais il y a forcément une dans un garbage collector et qui est difficilement prédictible). La communauté de Go en fait donc un autre usage et la question d'efficacité du code vu plus haut reste alors moins importante dans des contextes tel que l'implémentation d'un serveur HTTP - cela ne veut pas dire que Go est lent, bien au contraire, mais certaines problématiques refusent qu'il y est une latence non prédictible, et c'est dans ces contextes qu'on utilise le C où la gestion de la mémoire est bien plus fine.

La caractéristique unsafe des langages tel que le C est parfois aussi une qualité dans ce genre de système où faire des choses dangereuses comme ceci:

1
*(uint8_t*)0x1234 = 0xFF; 

devrait être possible. C'est une programmation bas niveau qui dépends énormément de l'architecture sur laquelle on travaille mais qui change complétement la donne par rapport à Go. Il n'est pas possible de faire ce genre de chose en OCaml ou en Haskell, et c'est normal, ils n'ont pas cette ambition. Go semblerait avoir cette ambition, de faire de la programmation bas niveau, sans pour autant en donner les outils. Rust permet de faire ce genre de code avec unsafe{} ce qui permet entre autre une isolation.

Conclusion

Pour moi, Go est un langage fragmenté par le choix entre safety et efficiency et qui n'a pas réussi. On a une communauté qui vise des logiciels dont le safety prime et des développeurs qui martèlent l'efficacité du code Go sans y arriver. Malheureusement, cette fragmentation apparaît dans les débats internes du langage où la communauté demande des outils plus haut niveau et où les développeurs refusent en disant que ça complexifierait trop le langage. Mais parfois ils cèdent et ça laisse des horreurs comme interface{}. Bref, si l'équipe de développement de Go ne veut pas s'avouer vaincu face à ses objectifs qui divergent par rapport à ceux de la communauté, je préfère passer mon chemin.

D'ailleurs, je rebondis rapidemment, y a t il des langages veritablement novateurs? Qui sorte de la conception objet par exemple, qui se pencherait plus sur du multithreading (=> le modele Entity Component par exemple)

Ricocotam

Difficile de trouver des langages vraiment novateurs car la plupart des paradigmes (programmation par contrat, programmation fonctionnelle, etc.) existent depuis longtemps mais les langages ultra-généralistes (auxquels C++ fait partie) vont avoir tendance, tout en adoptant une syntaxe, des performances et une compatiblité plus ou moins partielle avec les bibliothèques C/C++, à fournir des éléments de syntaxe spécifiques à ces paradigmes là où il fallait ruser jusqu'à présent. C'est le cas du langage D par exemple.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte