Il a un GC, il existe des techniques de programmation qui font qu'il est tout simplement plus nécessaire d'en avoir un dorénavant.
Utiliser des clôtures ou des structures de données cycliques est très pénible sans GC. Pour les structures, le besoin n'est pas forcément fréquent, mais les clôtures, j'en utilise souvent.
Il supporte les pointeurs du style void * comme en C.
Il n'y a pas de pointeurs du style void * comme en C, non. Ce qu'il y a, c'est un type interface particulier qui peut être utilisé comme une version restreinte et plus explicite du concept de variable en Python ou autres langages dynamiques. C'est très différent. Ça représente rarement une portion significative du code et, même lorsque c'est utilisé, c'est le plus souvent à l'aide de type-switchs qui ne peuvent pas provoquer d'erreurs au runtime.
Les développeurs laissent pourrir des problèmes et n'écoutent pas la communauté.
Chose qui peut s'appliquer à n'importe quel gros projet : impossible de satisfaire tous les utilisateurs. Il y en aura toujours pour se sentir oubliés parce qu'ils n'ont pas écoutés, mais ils oublient souvent que leurs besoins sont en conflits avec ceux d'autres utilisateurs, ou simplement non prioritaires. Par exemple, les utilisateurs de Rust et C++ qui aiment la compilation rapide pourraient se sentir oubliés. Leurs préférences sont juste en conflit avec celles d'autres utilisateurs du langage.
Go est écrit en Go, ce qui rend sa compilation sur des nouvelles plateformes pénible. C'est dingue cette obsession de développer quelque chose puis d'en faire un logiciel self-hosted.
C'est un désavantage en partie, mais bon, tu as gccgo aussi. Personnellement, je trouve que les avantages compensent largement les inconvénients : c'est un compilateur facile à maintenir par n'importe quel utilisateur du langage et qui compile en à peine une minute sur de vieilles machines (bref, ça m'est techniquement accessible, contrairement au compilateur Rust, par exemple).
Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
C'est l'impression que tu donnes en effet, celle de n'avoir jamais utilisé ce langage, mais d'être capable de le juger comme « inutile » sur la base d'une compréhension qui n'est pas basée sur un apprentissage du langage. C'est courant comme chose à faire mais, perso, je ne comprends pas.
Et puis, personnellement, si je devais me faire une idée sur un langage que je ne connais pas, je serais méfiant de m'appuyer sur des arguments techniques sortis de contexte et peut-être mal compris. Surtout pour un langage qui est quand même utilisé pour faire plein de choses. L'argument d'autorité n'est pas fiable en lui-même, mais dis-toi quand même que Go est utilisé avec satisfaction par plein de monde, pas forcément que des ignorants, et ses propres créateurs ont un bon bagage dans le domaine. De quoi se dire qu'un jugement rapide risque fortement d'être incorrect.
Perso, d'expérience, avec les langages de programmations, il y a deux types de personnes qui les détestent : ceux qui ne les ont pas utilisé, mais ont des préjugés basés sur leurs préférences dans des contextes qui ne s'appliquent pas ; et ceux qui ont été forcés de les utiliser dans un projet mal bâti.
[^] # Re: Pourquoi Rust ?
Posté par anaseto . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 5.
Utiliser des clôtures ou des structures de données cycliques est très pénible sans GC. Pour les structures, le besoin n'est pas forcément fréquent, mais les clôtures, j'en utilise souvent.
Il n'y a pas de pointeurs du style void * comme en C, non. Ce qu'il y a, c'est un type interface particulier qui peut être utilisé comme une version restreinte et plus explicite du concept de variable en Python ou autres langages dynamiques. C'est très différent. Ça représente rarement une portion significative du code et, même lorsque c'est utilisé, c'est le plus souvent à l'aide de type-switchs qui ne peuvent pas provoquer d'erreurs au runtime.
Chose qui peut s'appliquer à n'importe quel gros projet : impossible de satisfaire tous les utilisateurs. Il y en aura toujours pour se sentir oubliés parce qu'ils n'ont pas écoutés, mais ils oublient souvent que leurs besoins sont en conflits avec ceux d'autres utilisateurs, ou simplement non prioritaires. Par exemple, les utilisateurs de Rust et C++ qui aiment la compilation rapide pourraient se sentir oubliés. Leurs préférences sont juste en conflit avec celles d'autres utilisateurs du langage.
C'est un désavantage en partie, mais bon, tu as gccgo aussi. Personnellement, je trouve que les avantages compensent largement les inconvénients : c'est un compilateur facile à maintenir par n'importe quel utilisateur du langage et qui compile en à peine une minute sur de vieilles machines (bref, ça m'est techniquement accessible, contrairement au compilateur Rust, par exemple).
C'est l'impression que tu donnes en effet, celle de n'avoir jamais utilisé ce langage, mais d'être capable de le juger comme « inutile » sur la base d'une compréhension qui n'est pas basée sur un apprentissage du langage. C'est courant comme chose à faire mais, perso, je ne comprends pas.
Et puis, personnellement, si je devais me faire une idée sur un langage que je ne connais pas, je serais méfiant de m'appuyer sur des arguments techniques sortis de contexte et peut-être mal compris. Surtout pour un langage qui est quand même utilisé pour faire plein de choses. L'argument d'autorité n'est pas fiable en lui-même, mais dis-toi quand même que Go est utilisé avec satisfaction par plein de monde, pas forcément que des ignorants, et ses propres créateurs ont un bon bagage dans le domaine. De quoi se dire qu'un jugement rapide risque fortement d'être incorrect.
Perso, d'expérience, avec les langages de programmations, il y a deux types de personnes qui les détestent : ceux qui ne les ont pas utilisé, mais ont des préjugés basés sur leurs préférences dans des contextes qui ne s'appliquent pas ; et ceux qui ont été forcés de les utiliser dans un projet mal bâti.