Tu parles d'outillage, et c'est vrai que c'est un élément de plus en plus important pour qu'un langage de programmation réussisse.
Pour Go, j'en fais pas mal. J'apprécie l'outillage et la simplicité du langage. Mais je suis de plus en plus frustré par certaines limitations, et surtout le fait qu'il n'y ait toujours pas de solution en vue. Tu as parlé de généricité, c'est quelque chose dont je comprenais bien l'absence il y a quelques années pour laisser le temps à la core team d'y réfléchir et de trouver une solution qui colle au langage, mais ces dernières années, le langage n'évolue quasiment plus et on n'a toujours rien pour écrire des fonctions map ou filter, c'est très frustrant.
Pour la gestion des erreurs, les panic me dérangent assez peu. Par contre, je trouve très compliqué de bien gérer les erreurs remontées : on en sait jamais trop la liste des erreurs possible qu'une fonction peut remonter. Il y a des techniques pour enrober des erreurs et regrouper des erreurs de plusieurs traitements, ainsi que des paquets comme github.com/hashicorp/go-multierror, golang.org/pkg/errors et github.com/pkg/errors. Mais, dans la pratique, quand on utilise des bibliothèques externes, on se rend vite compte qu'il y a différentes stratégies pour exposer les erreurs et que les prendre correctement toutes en compte dans son application est un casse-tête.
Dans les autres points, il y a les pointeurs nils (plutôt que des optionals), l'absence de types somme, le manque d'un équivalent d'OTP pour ne pas avoir à constamment réinventer la roue avec les goroutines et channels (surtout que je vois régulièrement des gens utiliser incorrectement ces primitives lorsque je relis du code, signe que c'est loin d'être aussi simple que ce que les concepteurs du langage peuvent dire).
Pour Rust, j'ai l'impression que c'est un super langage pour faire des gros projets (un navigateur, une suite office, un système d'exploitation), mais c'est vraiment trop complexe et bas niveau pour mes besoins de développeurs d'applications principalement web. J'en vois pourtant passer de plus en plus : rien que dans les langages cités dans le journal, gleam et Scryer-Prolog sont codés en Rust. J'arrive généralement à lire le code, mais ça ne me donne pas envie d'en écrire.
[^] # Re: Go est lent, Rust est rouillé !
Posté par Bruno Michel (site web personnel) . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 9.
Tu parles d'outillage, et c'est vrai que c'est un élément de plus en plus important pour qu'un langage de programmation réussisse.
Pour Go, j'en fais pas mal. J'apprécie l'outillage et la simplicité du langage. Mais je suis de plus en plus frustré par certaines limitations, et surtout le fait qu'il n'y ait toujours pas de solution en vue. Tu as parlé de généricité, c'est quelque chose dont je comprenais bien l'absence il y a quelques années pour laisser le temps à la core team d'y réfléchir et de trouver une solution qui colle au langage, mais ces dernières années, le langage n'évolue quasiment plus et on n'a toujours rien pour écrire des fonctions map ou filter, c'est très frustrant.
Pour la gestion des erreurs, les panic me dérangent assez peu. Par contre, je trouve très compliqué de bien gérer les erreurs remontées : on en sait jamais trop la liste des erreurs possible qu'une fonction peut remonter. Il y a des techniques pour enrober des erreurs et regrouper des erreurs de plusieurs traitements, ainsi que des paquets comme github.com/hashicorp/go-multierror, golang.org/pkg/errors et github.com/pkg/errors. Mais, dans la pratique, quand on utilise des bibliothèques externes, on se rend vite compte qu'il y a différentes stratégies pour exposer les erreurs et que les prendre correctement toutes en compte dans son application est un casse-tête.
Dans les autres points, il y a les pointeurs nils (plutôt que des
optionals), l'absence de types somme, le manque d'un équivalent d'OTP pour ne pas avoir à constamment réinventer la roue avec les goroutines et channels (surtout que je vois régulièrement des gens utiliser incorrectement ces primitives lorsque je relis du code, signe que c'est loin d'être aussi simple que ce que les concepteurs du langage peuvent dire).Pour Rust, j'ai l'impression que c'est un super langage pour faire des gros projets (un navigateur, une suite office, un système d'exploitation), mais c'est vraiment trop complexe et bas niveau pour mes besoins de développeurs d'applications principalement web. J'en vois pourtant passer de plus en plus : rien que dans les langages cités dans le journal, gleam et Scryer-Prolog sont codés en Rust. J'arrive généralement à lire le code, mais ça ne me donne pas envie d'en écrire.