Antoine a écrit 5722 commentaires

en meme temps, avec l'ere des multi-cores (et celle des many-cores au tournant), cette contrainte devient de plus en plus archaique.

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

La syntaxe du C est honnêtement très potable. J'ai l'impression que la niche du Go, c'est précisément les gens qui aiment C, qui voudraient un truc un peu plus moderne mais qui ne peuvent pas supporter C++.
(C++ étant d'ailleurs l'un des langages principaux chez Google)

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.

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

Surtout que la signature n'est pas vérifiée pour les petites sommes (en-dessous de quelques centaines voire milliers d'euros).

Rien, juste une curiosité.

A la faveur d'une exception, je remarque qu'une partie de l'infrastructure Web de Go est écrite en Python:

(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

Globalement, les personnes qui ont essayé Go semblent convaincues que ce langage est promis à un grand avenir.

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.

été 2009 - délivrance des brevets en Europe

Hum.

avec leur produit Vivamens basé sur des "radix trees"

Vu que les "radix trees" sont loin d'être nouveaux, ça m'étonnerait que ce soit le facteur déterminant. Ceci dit, je ne suis pas spécialiste.

Mais le but de ce jeu n'est pas de faire un gros score non ?

Ça me rappelle une nouvelle de Buzzati.
(ou une citation de Chris Marker)

C'est un bug en mode 64 bits. Soit tu compiles en 32 bits, soit tu remplaces le sous-répertoire "gamma256" de l'archive avec la version CVS, qui corrige le souci :

cvs -d:pserver:anonymous@hcsoftware.cvs.sourceforge.net:/cvsroot/hcsoftware login

cvs -z3 -d:pserver:anonymous@hcsoftware.cvs.sourceforge.net:/cvsroot/hcsoftware co -P gamma256

Par exemple, le changement des règles de visibilité des variables dans python 2.1

Pour moi Python 2.1 n'est pas une version mineure, c'est une version majeure.
Par version mineure, j'entends par exemple le passage de la 2.6.4 à la 2.6.5.

C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles.

Je ne vois rien de tel dans la communauté, justement. Les similitudes sont assez grandes entre 2.x et 3.x pour que les gens continuent à échanger sans souci.

mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:

C'est un cas particulier. La nouvelle syntaxe de formatage de chaîne est un serpent de mer. Au début il était en effet prévu que l'ancienne meure totalement, mais cela a été repoussé aux calendes grecques.

Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.

Je ne pense pas, non. C'est un choix délibérément fait, pour introduire une version du langage plus agréable à utiliser. C'est aussi parce que la base d'utilisateurs n'est pas sous-estimée que le choix a été fait de ne pas repartir depuis zéro, mais simplement de faire les modifications les plus importantes. Les connaissances nécessaires pour développer avec la 2.x ou la 3.x ne sont pas significativement différentes, on s'en sort très bien en pratique.

Du reste, si la tendance continue, la base d'utilisateurs sera encore plus grande d'ici quelques années, lorsque (on l'espère) les versions 3.2/3.3 seront devenues les versions de choix pour développer.

Ils ont bien forké Debian.

Ben c'est comme ca depuis le debut

Ah, explique-nous alors. Je ne savais pas que "depuis le début", les fournisseurs mail inventaient des règles violant les RFC pour soi-disant optimiser leurs services.

Tous les acteurs autour se sont adaptes de la meme facon

Je n'ai pas l'impression. Tu as une liste à fournir ? Ou c'est juste un argument bidon ?

Par contre, les changements à la python sont beaucoup plus gênants, parce qu'ils changent la signification du code silencieusement (même aux mises à jour mineures)

Même aux mises à jour mineures ? Tu as un exemple ?

Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3)

Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
Au contraire, forker est assez propre dans la mesure où cela signale bien la rupture de compatibilité.

Sans compter qu'une "fonction lambda" (c'est-à-dire une fonction anonyme), ce n'est pas forcément une fermeture et vice-versa.

Le code de la route c'est pour la voie publique, la on parle d'une entreprise privee qui fourni un service.

Je trouve amusant de devoir expliquer sur Linuxfr qu'Internet (la « voie publique ») est censé être régi par des standards. Fournir un service à titre privé n'est pas une excuse pour inventer des règles à la noix qui contraignent tous les utilisateurs.

Leur serveurs (et leur argent), leurs regles.

Avec ce genre d'argument stupide, Internet n'existerait pas. Bravo le troll.

Le code de la route est connu et commun à tous. Les règles appliquées selon le jour et l'âge du capitaine par Google, c'est un peu la roulette russe.

Ca élimine au moins 99.99% des windows vérolés. Je pense qu'il y a peu de gens ayant ce type de machine qui ont un DNS et un reverse configurés.

Hum, et donc? Il reste le reverse attribué par le FAI, et il n'est pas très compliqué pour un ver ou virus quelconque de demander ce reverse avant de l'utiliser dans le HELO.
Non, franchement, je ne vois pas l'intérêt.

La machine s'authentifie avec son nom lors d'un "helo".
Si la machine ment (reverse dns ne correspond pas), ben forcément elle part pas d'un bon pied.

En même temps il n'y a aucun intérêt à mentir, puisque le "helo" ne détermine pas le nom de domaine possible pour l'expéditeur. Donc je ne vois pas trop l'intérêt de cette vérif-là.

En termes informatiques, ils offrent des couches d'abstraction haut-niveau (voip, etc.). Pour ceux qui veulent des couches d'abstraction bas-niveau (personnalisation de reverse, plage IPv6...), effectivement l'offre est un peu plus limitée.

Ceci dit je ne suis pas d'accord avec l'utilité d'un reverse. Cela ne sert que quand tu n'héberges qu'un seul domaine de toute façon.

Dans ta dépêche, tu as oublié un élément-clé : un certain Victor Stinner a obtenu les droits de commit et va pouvoir casser les buildbots sans demander la permission à personne :)

utiliser SPF et Domainkeys pour augmenter les chances que tes mails soient notés en "ham" par le SMTP en face

"Augmenter les chances", c'est le gros problème. Tu passes ton temps à courir derrière des boîtes noires dont tu ne connais pas le fonctionnement, dont le fonctionnement évolue sans que tu sois au courant, mais dans les bonnes grâces desquelles tu essaies de rester par divers expédients.

Encore faut-il la connaître et être sûr que ton FAI ne va pas reconfigurer son architecture dans ton dos...
Ceci dit j'ai pris le parti de créer un petit SMTP authentifié sur un serveur virtuel, ça m'a permis de configurer un SPF aux petits oignons.

Sachant que j'utilise une adresse ip dynamique, n'est-ce pas problématique ?

Tu peux configurer un peu ce que tu veux en SPF, y compris dire que n'importe quelle IP est autorisée à envoyer du mail pour ton domaine.
Une autre possibilité c'est d'avoir ton propre relais SMTP avec une IP statique sur un quelconque petit serveur (si tu en as déjà un).

RH voire même Mandriva pourront sans problèmes reprendre les rennes de ces projets.

Vaut mieux reprendre les rênes. Les rennes, ça fait du bruit, ça sent pas très bon et c'est encombrant.
(bon, c'est surtout quand ils sont plusieurs qu'il y a des problèmes)