Depuis, le développement continue d'avancer à un bon rythme. Des versions sont publiées tous les 10 à 15 jours.
Dernièrement, une proposition pour un mécanisme similaire aux exceptions a été discuté sur la liste de diffusion. C'est un exemple très révélateur de la manière d'avancer de l'équipe en charge de Go : ils ne se précipitent pas pour ajouter des fonctionnalités présentes dans d'autres langages parce qu'elles sont très demandées. Ils prennent le temps de réfléchir à chaque problème, et quand ils ont trouvé une piste qui semble pouvoir répondre à leurs exigences, ils publient une proposition sur la liste de diffusion. Il s'en suit des discussions qui permettent de raffiner la proposition et, sauf surprise, la proposition est intégrée dans la version suivante.
Côté communication, l'essentiel se passe sur le canal IRC #go-nuts sur freenode et sur la liste de diffusion Go-nuts. Un wiki a récemment été mis en place pour regrouper des informations sur l'écosystème de Go. Quelques jours plus tard, un blog officiel a suivi. Enfin, un dashboard permet de voir l'état des compilations sur les différentes architectures supportées.
Globalement, les personnes qui ont essayé Go semblent convaincues que ce langage est promis à un grand avenir.
Aller plus loin
- Go, le site officiel (36 clics)
- La liste de diffusion go-nuts (7 clics)
- Go Programming Language Resources (8 clics)
- La précédente dépêche LinuxFr sur Go (26 clics)
- La page wikipédia sur Go (61 clics)
- Ressources pour découvrir Go (83 clics)
# Extrait de "Effective Go"
Posté par snt . Évalué à 10.
>structure (if, for, switch, or select) on the next line. If you do, a
>semicolon will be inserted before the brace, which could cause
>unwanted effects. Write them like this
>if i < f() {
> g()
>}
>not like this
>if i < f() // wrong!
>{ // wrong!
> g()
>}
Wow. J'espère que le compilateur est assez intelligent pour prévenir qu'il y a quelque chose de louche, sinon ça va être sympa pour ceux qui sont multilangages et à qui il arrivera d'oublier une accolade en début de ligne..
[^] # Re: Extrait de "Effective Go"
Posté par 2PetitsVerres . Évalué à 4.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Extrait de "Effective Go"
Posté par Fabimaru (site web personnel) . Évalué à 3.
Syntaxe_JavaScript#Espaces_vides_et_points-virgules
[^] # Re: Extrait de "Effective Go"
Posté par Moonz . Évalué à 3.
Siouxerie du même genre (et pour la même raison): on ne dit pas:
> }
> else {
mais:
> } else {
# grand avenir
Posté par Antoine . Évalué à 4.
Heu, grosso modo on a interviewé trois personnes qui ont dit qu'ils aimaient Go. On ne sait pas comment ils ont été choisis, ni ce qu'auraient dit les (N-3) qui n'ont pas été interviewés.
À ce que j'en vois, Go semble susciter assez peu d'enthousiasme. Il arrive trop tard à mon avis, et la syntaxe foireuse ne va pas faciliter la tâche de ses supporters.
[^] # Re: grand avenir
Posté par rewind (Mastodon) . Évalué à 3.
Honnêtement, à part le fait que "c'est fait par Google donc saibien", je ne vois aucune amélioration objective qui me ferait passer à Go.
[^] # Re: grand avenir
Posté par Dr BG . Évalué à 6.
Et pourtant, C++ existe.
[^] # Re: grand avenir
Posté par Antoine . Évalué à 8.
(C++ étant d'ailleurs l'un des langages principaux chez Google)
[^] # Re: grand avenir
Posté par Moonz . Évalué à 9.
Pour l’avoir utilisé dans deux mini-projets (pour utilisation personnelle, mais qui tournent 100% du temps sur ma machine : un proxy DNS et un proxy HTTP):
Les plus:
- Passé quelques surprises, on retrouve finalement rapidement ses marques quand on a fait du C. Et je code plus efficacement qu’en C, au final (grâce, entre autre, aux types de base de bien plus haut niveau)
- Le système de typage est parfait. Disons plus modestement : c’est celui dont j’avais toujours rêvé
- Comme Python, "piles inclues" (librairie standard bien fournie)
- Le couple goroutine + channel, c’est également magique dès lors que tu as du multi-threading ; mon proxy DNS a un cache global dans lequel chaque client a une tâche lectrice et une tâche écrivain dessus. En multitâche classique, c’est le mal de crâne assuré pour synchroniser tout ce joli monde. En go, ça se fait tout seul (pas un seul mutex/sémaphore de tout le programme !)
- Le truc secondaire sur papier, absolument génialissime (et c’est encore un euphémisme) en pratique : le mot-clé defer.
Les moins:
- Le plus gros point, très gênant : le GC laisse passer des fuites de mémoire. Actuellement, mon proxy DNS tourne depuis trois jours, et utilise plus de 100 Mo de mémoire. Si je le redémarre, il n’en utilise plus que 5 Mo (et vu comme il est codé, le redémarrage ne devrait pas influer sur l’utilisation mémoire: le cache est sauvegardé sur disque puis rechargé au lancement)
- La librairie HTTP de base est… comment dire… totalement merdique. Ça c’est amélioré dans la version en développement, mais il y a encore un peu de boulot
- Interfaçage avec le C pas toujours trivial (et dès qu’il y a des pointeurs de fonction, ça devient VRAIMENT horrible)
- Ce que GCC met en "warning: unused xxx", Go en fait une erreur. C’est très énervant lors de la mise au point.
Pour ma part, il est définitivement adopté pour tout ce qui est "petits serveurs bas niveau" (typiquement : proxy HTTP qui ne touche pas au contenu des pages, proxy DNS, et pour la suite : filtre milter)
[^] # Re: grand avenir
Posté par paul . Évalué à 6.
[^] # Re: grand avenir
Posté par Moonz . Évalué à 2.
(et je fais une allergie aux langages inspirés de Prolog ;))
[^] # Re: grand avenir
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
>> (et je fais une allergie aux langages inspirés de Prolog ;))
Et moi, je déteste les choux de Bruxelles, car je n'aime pas faire de la planche à voile.
Rassure moi, « langage fonctionnel » et « prolog » sont bien indépendants dans ta phrase, là ?
[^] # Re: grand avenir
Posté par Moonz . Évalué à 1.
Oui, pourquoi ?
[^] # Re: grand avenir
Posté par VoixOff . Évalué à 1.
# Python
Posté par Antoine . Évalué à 4.
(résultat de http://godashboard.appspot.com/benchmarks )
Traceback (most recent call last):
File "/base/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 510, in __call__
handler.get(*groups)
File "/base/data/home/apps/godashboard/3.340308809368074859/gobuild.py", line 363, in get
page = self.compute(num)
File "/base/data/home/apps/godashboard/3.340308809368074859/gobuild.py", line 369, in compute
benchmarks, builders = benchmark_list()
File "/base/data/home/apps/godashboard/3.340308809368074859/gobuild.py", line 524, in benchmark_list
benchmarks = [r.benchmark for r in q.fetch(1000)]
File "/base/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1626, in fetch
raw = raw_query.Get(limit, offset, rpc=rpc)
File "/base/python_lib/versions/1/google/appengine/api/datastore.py", line 1240, in Get
limit=limit, offset=offset, prefetch_count=limit, **kwargs)._Get(limit)
File "/base/python_lib/versions/1/google/appengine/api/datastore.py", line 1167, in _Run
datastore_pb.QueryResult(), rpc)
File "/base/python_lib/versions/1/google/appengine/api/datastore.py", line 186, in _MakeSyncCall
rpc.check_success()
File "/base/python_lib/versions/1/google/appengine/api/apiproxy_stub_map.py", line 474, in check_success
self.__rpc.CheckSuccess()
File "/base/python_lib/versions/1/google/appengine/api/apiproxy_rpc.py", line 126, in CheckSuccess
raise self.exception
MemoryError
[^] # Re: Python
Posté par Albert_ . Évalué à 2.
[^] # Re: Python
Posté par mansuetus (site web personnel) . Évalué à 1.
http://golang.org/doc/go_faq.html#Is_Google_using_go_interna(...)
For instance, the server behind http://golang.org is a Go program; in fact it's just the godoc document server running in a production configuration.
ce qu'on peut traduire (bourré) en :
golang.org tourne sur du go
Notons qu'ils ne parlent que de golang.org et pas du serveur sus-cité, mais je pense que la remarque vient de là.
[^] # Re: Python
Posté par ribwund . Évalué à 2.
[^] # Re: Python
Posté par Antoine . Évalué à 2.
# facilité et puissance
Posté par stopspam . Évalué à 2.
Python est multi-plateforme, libre, vraiment bien supporté et surtout on peut tout faire avec ! (web/appli/daemon/script...). Et ce qui fait la différence est sa lisibilité et sa compréhension.
A chaque fois qu'un nouveau langage sort, je fais systématiquement la comparaison avec python. Au final python winner++.
[^] # Re: facilité et puissance
Posté par mister popo ポポ (site web personnel) . Évalué à 10.
Python fait parti des langages "officiels" de Google, avec C++ et Java, ils ont même Mr Python qui bosse chez eux : Guido Von Rossum. Google App Engine est d'abord sorti en python, comme autre exemple.
Sauf que Python, que j'aime beaucoup a UN problème, il gère les threads comme une bouse. Ca existe, mais il y a un gros lock qui pourri les performances. Tu peux avoir des taches en parallèle, mais pas profiter de la puissance d'une architecture multicore. Antoine Pitrou a proposé des patchs pour corriger ça, mais ça ne semble pas encore être le nirvana.
L'idée de Go est d'avoir un langage qui ne soit pas chiant à compiler (comme C++), mais qui gère les multicore comme il faut (pas comme Python).
[^] # Re: facilité et puissance
Posté par Antoine . Évalué à 10.
Ça ne sera le nirvana que si le GIL (gros verrou de l'interpréteur) est supprimé un jour, et ce n'est pas pour demain... car beaucoup de boulot, très complexe surtout si on ne veut pas que les performance mono-thread souffrent au passage.
Pour info, même PyPy (réimplémentation complète de Python en Python) a un GIL.
Mes patches ont simplement pour objet d'éliminer les inefficacités au niveau de la gestion du verrou lui-même, pas de le supprimer.
[^] # Re: facilité et puissance
Posté par Sebastien . Évalué à 2.
en meme temps, avec l'ere des multi-cores (et celle des many-cores au tournant), cette contrainte devient de plus en plus archaique.
ceci etant, jython ou ironpython pourrait arriver a la rescousse (puisqu'ils n'ont pas de GIL)
[enfin bon, tant que 'multiprocessing' marche et que cython facilite l'ecriture de modules...]
[^] # Re: facilité et puissance
Posté par Antoine . Évalué à 4.
Non pas du tout.
Premièrement parce qu'il y a beaucoup de problèmes qui ne sont pas (ou médiocrement, ou difficilement) parallélisables.
Deuxièmement parce qu'il y a toujours des situations où tu n'as qu'un ou deux coeurs à disposition. Exemple : virtualisation (notamment, hébergements plus ou moins bon marché). Ou bien : petits appareils portables.
Troisièmement parce que ce n'est pas parce qu'il y a plein de coeurs que tu veux qu'ils soient accaparés par un programme unique (plutôt qu'affectés à plein de programmes différents).
[^] # Re: facilité et puissance
Posté par Sebastien . Évalué à 2.
bon je vois ca depuis ma lunette 'python comme langage pour scientifiques' donc en effet, mon terrain de jeux c'est le bi/quad/octo coeur avec 2Go par coeur.
je n'ai pas les stats (peut-etre que la PSF les a?) mais il serait sans doute interessant de savoir sur quel type de plateforme python est 'le plus' utilise...
[^] # Re: facilité et puissance
Posté par Antoine . Évalué à 2.
Je ne sais pas. Je pense que l'informatique scientifique est une niche pour Python. Ceci dit les extensions C spécialisées ne relâchent pas déjà le GIL ? Il faudrait qu'elles le fassent.
[^] # Re: facilité et puissance
Posté par pifou . Évalué à 5.
Concernant Go, je pense que l'idée d'inventer un langage avec quelques principes forts pour voir ce que ça donne est intéressante. Par contre j'attendrai que ce langage apporte vraiment quelque choses de nouveau pour m'y intéresser réellement.
A mon avis, tant qu'on reste dans du développement 'procédural' (comprendre non fonctionnel) qu'importe le langage, normalement un développeur devrait pouvoir se débrouiller correctement assez rapidement.
J'ai appris à développer sur Java en 99. Ensuite j'ai fait un peu C. J'ai appris la programmation système (socket, IPC, traitement IO) avec Perl. Je me suis ensuite extasié devant Smalltalk, un vrai langage 100% objet (ça fait un choc en venant du monde Java).
Quand j'ai voulu faire de l'objet en Perl, j'ai commencé à pleurer (depuis je me soigne). J'ai donc commencé à regarder du coté de Python ... puis par miracle (grâce à DLFP) j'ai pris connaissance d'un autre langage de script : Ruby. Je pense que j'ai eu le même 'coup de foudre' avec Ruby qu'avec Smalltalk (avec l'avantage que c'est moins has-been, voir has-never-been).
Évidemment depuis je bosse dans une SSII ... ça apprend à relativiser ses prétentions techniques. J'ai réussi à éviter le développement Java (bien qu'ayant au départ un CV 95% Java) mais j'ai pas encore réussi à faire du développement Ruby ... je me cantonne à faire du Perl objet (mais c'est déjà bien cool).
Bref, tout ce passage vieux schnock pour dire que la locution 'Carpe Diem' s'applique aussi très bien en matière de développement.
[^] # Re: facilité et puissance
Posté par mister popo ポポ (site web personnel) . Évalué à 3.
[^] # Ruby, c’est fini.
Posté par Arthur Accroc . Évalué à 2.
Moi aussi (pour Ruby, je n’ai jamais essayé Smalltalk).
Et puis j’ai voulu utiliser un destructeur et l’idylle s’est définitivement terminée aussi rapidement qu’elle avait commencé.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ruby, c’est fini.
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
La méthode Ruby pour traiter ce genre de cas est donc à mon avis assez élégante :
File.open "youhou" do |f|
f.write "ceci est un exemple"
end
Après le end, tu es sûr que ton fichier est bien fermé.
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 3.
Oui c'est très bien quand la durée de vie de ton objet est limitée lexicalement.
(Python a le mot-clé "with" qui fonctionne sur le même principe)
Mais il y a des situations où tu veux que ton objet survive à la fonction courante, tout en assurant une déallocation de ressource lorsque plus personne ne le référence.
(en Python, tu peux aussi jouer avec les weakrefs, mais __del__ est plus simple à utiliser)
[^] # Re: Ruby, c’est fini.
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Pourrais-tu donc me donner un exemple concret d'utilisation d'un destructeur, qui ne pose pas de problème avec le garbage collector (c'est-à-dire que ne pas savoir quand le destructeur est appelé n'est pas un problème), et qui ne puissent pas se résoudre simplement avec la méthode Ruby ?
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 3.
Effectivement c'est une constrainte assez restrictive.
Ceci dit, une socket par exemple, tu aimerais qu'elle soit fermée lorsque tu n'en as plus besoin, mais s'il s'écoule quelques secondes avant cette fermeture, c'est acceptable.
(après tout dépend bien sûr de la réactivité du GC... je ne connais pas Ruby)
et qui ne puissent pas se résoudre simplement avec la méthode Ruby ?
Comme j'ai dit : toute situation où la ressource (fichier, socket, connexion SGBD...) n'est pas simplement locale à une fonction, mais ouverte pour un certain temps et éventuellement utilisée par plusieurs objets ou modules. C'est pas bien compliqué à imaginer, et assez courant :)
[^] # Re: Ruby, c’est fini.
Posté par Arthur Accroc . Évalué à 0.
Moi aussi, je suis convaincu que le choix d’un garbage collector est une erreur de conception, surtout pour un langage orienté objet.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ruby, c’est fini.
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Ruby, c’est fini.
Posté par yellowiscool . Évalué à 2.
Avec un garbage collector, t'as les inconvénients, tout le temps.
Envoyé depuis mon lapin.
[^] # Re: Ruby, c’est fini.
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Et c'est quoi les inconvénients ? Parce que si tu parles des destructeurs, ça revient à remplacer une demande de libération de mémoire par un appel manuel à un destructeur, donc il ne peut y avoir que des choses en moins.
[^] # Re: Ruby, c’est fini.
Posté par yellowiscool . Évalué à -1.
Après même si je ne fais pas du temps réel, j'ai lu que le déclenchement du garbage collector pause des problèmes pour le temps réel. Bon je te l'accorde qu'en ruby, on s'en fiche.
C'est pas grand chose comme inconvénients, mais ça me gonfle vraiment d'avoir un redmine qui prends un quart de la ram de mon serveur, de devoir relancer firefox régulièrement, d'avoir mon ordi qui swap à chaque fois que je lance eclipse, ou qu'un bébé phoque meurt à chaque fois que le garbage collector de la machine virtuelle de java se déclenche automatiquement (heureusement pour les phoques, ça arrive très rarement).
Envoyé depuis mon lapin.
[^] # Re: Ruby, c’est fini.
Posté par Bruno Michel (site web personnel) . Évalué à 1.
[^] # Re: Ruby, c’est fini.
Posté par windu.2b . Évalué à 4.
1 http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
[^] # Re: Ruby, c’est fini.
Posté par kowalsky . Évalué à 6.
====> [ ]
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 6.
Il fait combien de lignes, ton programme qui n'a plus vraiment de problèmes à la fin ?
Parce que des fuites mémoire dans des programmes C, on en trouve régulièrement, y compris dans des projets vachement mûrs.
[^] # Re: Ruby, c’est fini.
Posté par yellowiscool . Évalué à 0.
Si la fuite est trop importante, elle est corrigée.
Envoyé depuis mon lapin.
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 3.
[^] # Re: Ruby, c’est fini.
Posté par yellowiscool . Évalué à 2.
Puis même si le bug n'est pas corrigé, ça fonctionne aussi bien qu'un truc avec ramasses miettes. C'est pratique.
Envoyé depuis mon lapin.
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 2.
Ce n'est pas la question. Tu as l'air de penser que c'est trivial de corriger de tels bugs et que la charge de travail occasionnée ne serait pas mieux utilisée ailleurs (ce qui serait le cas en utilisant une gestion mémoire automatique intégrée au langage).
Au-delà de la charge de travail liée à la correction des bugs, il y a celle, encore plus grande, liée au fait de devoir gérer la mémoire explicitement, ce qui réclame une attention de tous les instants et rend également le code beaucoup plus verbeux. Là encore, beaucoup de temps perdu qui aurait pu être utilisé à des tâches plus productives.
Puis même si le bug n'est pas corrigé, ça fonctionne aussi bien qu'un truc avec ramasses miettes.
C'est les bisounours qui colmatent les fuites ? Bonne chance en tout cas.
[^] # Re: Ruby, c’est fini.
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 4.
Si les développeurs passent plus de temps à traquer les bugs à la noix (fuites de mémoire), ils passeront moins de temps à ajouter des fonctionnalités, etc. Et ça impacte l'utilisateur que tu es.
[^] # Re: Ruby, c’est fini.
Posté par yellowiscool . Évalué à 2.
Je connais pas grand monde qui part en croisade contre les fuites mémoires sur gnome, et pourtant gnome ne consomme pas énormément de ram. Et on peut pas dire que l'utilisateur en est mécontent.
Envoyé depuis mon lapin.
[^] # Re: Ruby, c’est fini.
Posté par Antoine . Évalué à 2.
On va arrêter là, car la discussion devient circulaire. « Il suffit » de corriger les bugs (« bêtes erreurs »), ok :)
[^] # Re: Ruby, c’est fini.
Posté par reno . Évalué à 1.
Comme c'est le concepteur d'Eiffel, il a quelques solide references..
Tu as quoi comme arguments pour soutenir ton affirmation?
[^] # Re: facilité et puissance
Posté par Damien (site web personnel) . Évalué à 0.
Oui mais bon, autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968…
http://www.cowlark.com/2009-11-15-go/
[^] # Re: facilité et puissance
Posté par Moonz . Évalué à 1.
Pourquoi ?
[^] # Re: facilité et puissance
Posté par Damien (site web personnel) . Évalué à -1.
Plutôt que de réinventer un langage de zéro, autant adopter Algol 68, qui est déjà spécifié proprement… il aurait suffit de remettre un compilo au gout du jour.
Enfin bon ce qui me frustre surtout c'est le manque d'inventivité. La plupart des langages qui sortent maintenant sont des resucées de ce qui existe déjà, un peu de ci, un peu de ça, et il n'y a que rarement une nouveauté réelle ou une approche intéressante d'un problème connu : les modules de Newspeak, les séquences en Clojure… éventuellement les goroutines, mais c'est pas bien différents de ce qu'il y a en Erlang…
[^] # Re: facilité et puissance
Posté par Moonz . Évalué à 3.
Ce n’est pas ce que tu as dit. Ce que tu as dit, c’est, je cite « autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968… » Et je ne vois par pourquoi "Algol 68 le faisait avant" devrait interdire Google de reprendre ces concepts.
Quant à la pertinence de faire un nouveau langage… Je connais pas Algol, mais de cet article, je vois quelques différences :
- type "map" de base
- les channels sont typés
- mot clef "defer"
- le système de typage basé sur les interfaces est de loin plus riche que le comparatif franchement limité "object orientation" le montre
Repartir de zéro permet d’avoir les coudées franches sur ce genre de choses
> Enfin bon ce qui me frustre surtout c'est le manque d'inventivité.
Je ne pense pas que ce soit le but de ce langage
[^] # Re: facilité et puissance
Posté par Fabien Engels . Évalué à 10.
Au final python winner++.Amusant que tu utilises cette syntaxe alors qu'elle n'est pas utilisable en Python ... ;p
[^] # Re: facilité et puissance
Posté par monde_de_merde . Évalué à -4.
# Un article sur Go
Posté par Bruno Michel (site web personnel) . Évalué à 5.
# Ah ouais, quand même !
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
>> ils ne se précipitent pas pour ajouter des fonctionnalité
>> Ils prennent le temps de réfléchir à chaque problème
>> sauf surprise, la proposition est intégrée dans la version suivante.
Révolutionnaire !
Sinon, tu peux tenter de lire les archives des mailing lists du langage Scheme pour voir un peu ce que c'est que « réfléchir à chaque problème. » D'ailleurs, en Scheme, sauf surprise, rarement sont les propositions intégrées dans la version suivante…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.