Merci pour ce retour constructif et très important pour nous.
Je partage en grande partie tes constats, et je vais prendre en compte tes propositions. Par contre, cela risque de prendre un peu de temps. On ne fait pas changer de direction à un mammouth comme LinuxFr facilement.
> Mais si tu vires la tribune t'es mort !
Note pour plus tard : ne pas oublier d'embaucher des gardes du corps.
Voici quelques exemples de commentaires aigris tirés des dernières dépêches que j'ai écrites :
« ça, c'est de la dépêche.
hier mon micro-onde a décidé de ne plus marcher.
j'ai le droit d'en parler, il marche avec du java. Comme quoi, javasaynul ! »
« 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… »
Devise est un plugin d'authentification pour Rails qui a la bonne idée de fonctionner avec Rails 3 (contrairement au précédent plugin, authlogic). http://github.com/plataformatec/devise
> Tu ne penses pas que le développement du moteur d'un site communautaire pourrait au moins être un peu moins opaque ?
Je n'aime pas communiquer sur des projets dont je ne sais pas s'ils vont aboutir et sur lesquels les gens ne vont pas pouvoir contribuer. Pour le premier point, je pense être maintenant relativement confiant que ça va marcher. Pour le second, il reste du travail faire : ça manque sérieusement de docs, d'un tracker, etc. Mais ça devrait changer dans les semaines à venir, et quand ce sera fait, je communiquerais.
> Bref, est-ce qu'il est possible d'avoir un avis des administrateurs du site sur ce projet ?
Oui, bien sur :
> Est-t'il viable ?
Oui. J'ai de l'expérience dans les applis Rails, et la question des perfs ne me fait vraiment pas peur.
> nécessaire ?
À court terme, pas vraiment. Le site actuel fonctionne sans trop de problèmes et on est capable d'y apporter de petites évolutions. Mais on sent bien que ça ne pourra pas durer comme ça encore plusieurs années. Par exemple, on ne prendra plus le risque de s'essayer à une mise à jour de templeet : on sait que le système de cache a été modifié, que cela a introduit des bugs, et comme c'est un des pires bouts de code que je n'ai jamais vu, on n'est pas capable de le corriger.
> réalisable ?
J'espère bien ;)
Si tu es décidé à contribuer, attends encore un peu. Pour le moment, ce n'est vraiment pas évident : pas facile à installer, pas de doc, pas de tracker, etc. Mais ça devrait changer d'ici un mois.
Je te conseille d'essayer MongoDB. Ça me semble être une excellente solution pour ta demande, et c'est vraiment plus simple à prendre en main que CouchDB.
> il se pourrait que des transactions financières aient lieu et que celles-ci doivent être enregistrées, et il peut alors devenir gênant d'en perdre les traces
Tu peux partir sur MongoDB, et le jour où tu as à gérer des transactions financières, enregistrer ces transactions dans une autre base de données.
> Rien n'est parfait puisque MongoDB n'est qu'éventuellement consistante.
Le théorème CAP nous dit effectivement qu'on ne pourra jamais avoir de bases de données parfaites : entre Consistency, Availability et Network Partitions, on ne pourra jamais avoir que deux des trois propriétés en même temps.
Autre stats : les utilisateurs loggés hier et qui ont postés au moins un commentaire (toujours sans les 37 moules). 416 dépêches pour 708 utilisateurs -> 0,59 dépêches par utilisateurs.
Le rapport est assez subjectif, mais pour ma part, quand je tombe sur des commentaires que je considère comme aigris, ce sont souvent des moules qui les ont écrits (à la louche, dans 50% des cas, alors que les moules sont très loin de représenter 50% des utilisateurs qui postent des commentaires).
> J'en pense qu'il serait plus judicieux de comparer la proportion de moules soumettant des dépêches à la proportion de non-moules soumettant des dépêches
Nous avons donc 21 dépêches pour 37 moules, soit 0,57 dépêches par moule. Hier, 1303 utilisateurs se sont connectés (sans compter les 37 moules). Sur la même période (2009), ils ont proposés 435 dépêches, soit 0,33 dépêches.
> ce lien n'est plus présent nulle part sur le site
Si, il est dans le plan du site : http://linuxfr.org/plan/ mais c'est vrai que l'on ne le met pas en avant.
> Perso j'estimes qu'il n'y a qu'une seule chose a dire sur ce journal
C'est une dépêche et pas un journal, sinon le problème ne se poserait pas.
> Les moderateurs ont vraiment fait un travail pitoyable
La critique est facile, surtout quand on ne sait pas le travail de relecture et de modération qu'il y a eu. La dépêche est loin d'avoir fait l'unanimité chez les modérateurs, et elle est restée pendant plusieurs jours dans un status quo. On a fini par l'accepter pour diverses raisons plus ou moins bonnes, parce qu'il fallait bien prendre une décision à ce sujet.
> ce n'est qu'un ramassis d'invectives vues d'un seul cote
Certes. Si tu veux nous éclairer sur l'autre coté, n'hésite pas à proposer une dépêche.
> par un compte cree il y a 2 jours et qui n'a jamais rien poste d'autre d'ailleurs
Oui, c'est courant que des personnes créent des comptes juste pour proposer une dépêche et répondre aux commentaires dans cette dépêche. Heureusement d'ailleurs qu'ils le font, parce que les utilisateurs de longue date proposent de moins en moins de dépêches, mais écrivent de plus en plus de commentaires aigris.
En fait, l'équipe de modération est même un peu plus tolérante avec les nouveaux afin de ne pas les décourager dès le début. On n'accepte pas n'importe quoi pour autant et, encore une fois, pour cette dépêche, ça a été très limite.
> cela veut dire admettre un nombre incalculable de conneries.
Pour autant que je sache, ce ne sont pas des conneries, même si je reconnais que c'est présenté d'un point de vue biaisé.
> j'esperes que c'est pas le manque de news qui vous a incite a accepter ce torchon.
Malheureusement, si, ça a joué. Depuis le début de l'année, nous sommes dans une période creuse et nous sommes donc un peu moins regardant sur les dépêches. Nous n'acceptons pas n'importe quelle dépêche, mais si ça continue, ça va être vraiment difficile pour LinuxFr.
> Par contre, pas de stats effectuées directement auprès de sourceforge, github et analogues.
Pour ceux qui sont intéressés par les stats de github, la page http://github.com/languages donne le classement des langages pour les dépôts github. Ça représente 280 000 dépôts (380 000 en comptant les forks) d'après http://github.com/blog/620-committing-like-crazy . Le podium est alors composé de Ruby, Javascript et Perl.
Je n'ai pas trouvé les stats de bitbucket, mais j'imagine que Python doit y être le grand gagnant.
Par curiosité, qu'est-ce que tweetdeck fait de mieux que gwibber ou pino ? Des fonctionnalités en plus ? L'interface est mieux pensée / plus agréable ? Ça gère plus de réseaux sociaux ?
Vas-y, tu as le droit de proposer une dépêche sur le sujet ;-)
Ça pourrait être très intéressant. En tout cas, moi, j'aimerais bien lire des choses sur ce sujet, mais je n'ai pas encore pris le temps de chercher des infos sur ce sujet. Donc, si tu connais bien le sujet ou que tu es prêt à y passer un peu de temps, je t'en prie, fais nous une jolie dépêche sur le sujet.
> Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain.
Moi aussi, mais avant d'en arriver là, il aura fallu coder pendant des dizaines d'heures. Et coder avec des langages dynamiques va généralement bien plus vite qu'avec des langages statiques. Quand je fais du développement web, je préfère la vitesse de développement aux performances.
> Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.
Je développe également des applications Rails. Certaines d'entre elles font des millions de visites par mois, tournent sur un seul serveur dédié et le goulot d'étranglement n'est jamais Ruby mais la base de données.
> Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)
Ouais, c'est connu, les programmes en haskell, ça court les rues. Le seul programme en haskell que je connais, c'est darcs, et il est connu pour deux choses : être le meilleur DVCS sur le papier, et avoir des performances qui varient entre le meilleur et le pire sans que personne ne sache trop pourquoi.
Pour 'gitit', il t'a fallu combien de temps pour le recompiler ? Lancer les tests t'aurait pris combien de temps ?
De mon expérience, compiler et lancer des tests sur un projet prennent souvent un temps comparable.
Sinon, concernant le typage statique, je considère que c'est une forme de tests que l'on t'oblige à écrire. Mais je considère que ce sont des tests assez mauvais et quitte à passer du temps à écrire des tests, je préfère en écrire qui soient pertinents. Par contre, le typage statique a un effet de bord très intéressant : les performances.
Pour le développement d'applications web, les performances sont souvent une considération secondaire. On cherche plutôt la vitesse de développement, et là, les langages dynamiques sont souvent très efficaces. Et le typage statique n'apporte souvent pas grand chose en terme de fiabilité, car une très grande partie des objets manipulés sont de toute façon des chaînes de caractères.
D'habitude, quand on essaye de troller, on y va avec un minimum de finesse.
Enfin, je vais quand même répondre : Ruby et Python sont deux langages très proches, mais ils ne sont pas pour autant totalement équivalent. Par exemple, je vois au moins un domaine dans lequel Ruby excelle et Python est à la traine : l'écriture de Domain Specific Language. Cette force permet à des bibliothèques Ruby de devenir des références dans leur domaine au point d'être copié dans dans de nombreux langages, mais jamais de manière aussi élégante. C'est le cas de Sinatra[1] dans le domaine des API Rest, de rspec[2] pour le Behaviour Driven Development ou de Chef[3] pour l'automatisation de l'infrastructure.
On pourrait également retourner la question. Je serais curieux de savoir quels sont les points où Python brille et où Ruby n'est pas la hauteur. Le support de Google, ça ne compte pas ;-)
Je suis d'accord que le mouvement NoSQL est très semblable au mouvement vers les langages dynamiques.
Par contre, tu sembles penser que les langages statiques permettent d'écrire des applications plus fiables. Les études semblent au contraire montrer que le nombre de bugs est proportionnel au nombre de lignes de code et les langages dynamiques permettent généralement d'écrire un même code de manière plus courte. D'autre part, le vrai facteur qui améliore grandement la fiabilité d'un programme est la présence de tests. Les langages dynamiques proposent généralement des bibliothèques de tests bien plus avancées et pratiques à utiliser que celles pour des langages compilés. Mais, au final, peu importe que ce soit un langage statique ou un langage dynamique, un bon développeur écrira toujours du code de meilleure qualité qu'un développeur débutant (mieux testé, et donc plus fiable).
Tu sembles aussi sous-entendre que les "vrais" développeurs utilisent des langages statiques, alors que les langages dynamiques sont tout juste bons pour les scripteurs PHP du dimanche. C'est faux. De très bons développeurs utilisent des langages dynamiques par choix. Il suffit par exemple de regarder les sites à fort trafic pour croiser de nombreux exemples : facebook (PHP), twitter (Ruby), wikipedia (PHP), etc.
Le fait que ce soit du Erlang doit jouer, mais ça n'explique pas tout à mon avis.
Si on prend un autre domaine, les files d'attentes, il y a également une forte concurrence entre différents produits. Le gagnant (à mes yeux) est RabbitMQ, qui est également en Erlang. Et pourtant, il y avait une concurrence avec d'autres projets en C (beanstalkd), Java (ActiveMQ) ou Ruby (Starling).
[^] # Re: Avis d'une moule
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ? (suite). Évalué à 10.
Je partage en grande partie tes constats, et je vais prendre en compte tes propositions. Par contre, cela risque de prendre un peu de temps. On ne fait pas changer de direction à un mammouth comme LinuxFr facilement.
> Mais si tu vires la tribune t'es mort !
Note pour plus tard : ne pas oublier d'embaucher des gardes du corps.
[^] # Re: Commentaires aigris
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ? (suite). Évalué à 6.
« ça, c'est de la dépêche.
hier mon micro-onde a décidé de ne plus marcher.
j'ai le droit d'en parler, il marche avec du java. Comme quoi, javasaynul ! »
« 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… »
« ça sert à quoi Ruby alors qu'il y a python ? »
[^] # Re: Mouarf
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 3.
Devise est un plugin d'authentification pour Rails qui a la bonne idée de fonctionner avec Rails 3 (contrairement au précédent plugin, authlogic). http://github.com/plataformatec/devise
> Tu ne penses pas que le développement du moteur d'un site communautaire pourrait au moins être un peu moins opaque ?
Je n'aime pas communiquer sur des projets dont je ne sais pas s'ils vont aboutir et sur lesquels les gens ne vont pas pouvoir contribuer. Pour le premier point, je pense être maintenant relativement confiant que ça va marcher. Pour le second, il reste du travail faire : ça manque sérieusement de docs, d'un tracker, etc. Mais ça devrait changer dans les semaines à venir, et quand ce sera fait, je communiquerais.
[^] # Re: Mouarf
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 4.
Oui, bien sur :
> Est-t'il viable ?
Oui. J'ai de l'expérience dans les applis Rails, et la question des perfs ne me fait vraiment pas peur.
> nécessaire ?
À court terme, pas vraiment. Le site actuel fonctionne sans trop de problèmes et on est capable d'y apporter de petites évolutions. Mais on sent bien que ça ne pourra pas durer comme ça encore plusieurs années. Par exemple, on ne prendra plus le risque de s'essayer à une mise à jour de templeet : on sait que le système de cache a été modifié, que cela a introduit des bugs, et comme c'est un des pires bouts de code que je n'ai jamais vu, on n'est pas capable de le corriger.
> réalisable ?
J'espère bien ;)
Si tu es décidé à contribuer, attends encore un peu. Pour le moment, ce n'est vraiment pas évident : pas facile à installer, pas de doc, pas de tracker, etc. Mais ça devrait changer d'ici un mois.
[^] # Re: linuxFR
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Microblogging : envie d'un Twitter rien qu'à vous ?. Évalué à 2.
suiveur ?
> retweet <-> recycle <-> diffuser
Je garderais bien le préfixe 're' : republier ? rediffuser ?
> timeline <-> timeline <-> ???
Frise chronologique ?
# MongoDB++
Posté par Bruno Michel (site web personnel) . En réponse au message Base NoSQL pour appli métier en mode Web. Évalué à 3.
> il se pourrait que des transactions financières aient lieu et que celles-ci doivent être enregistrées, et il peut alors devenir gênant d'en perdre les traces
Tu peux partir sur MongoDB, et le jour où tu as à gérer des transactions financières, enregistrer ces transactions dans une autre base de données.
> Rien n'est parfait puisque MongoDB n'est qu'éventuellement consistante.
Le théorème CAP nous dit effectivement qu'on ne pourra jamais avoir de bases de données parfaites : entre Consistency, Availability et Network Partitions, on ne pourra jamais avoir que deux des trois propriétés en même temps.
[^] # Re: Foutaises !
Posté par Bruno Michel (site web personnel) . En réponse au journal Le langage C serait redevenu le langage le plus utilisé. Évalué à 3.
Il y a aussi quelques millions de français, et on a bien des sondages pour chaque élection.
Ça ne veut pas dire que ce soit super précis, mais pour ceux que ça intéresse, ça reste toujours mieux que rien.
[^] # Re: ffeur.
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 2.
[^] # Re: Euh...
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 2.
[^] # Re: ffeur.
Posté par Bruno Michel (site web personnel) . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 7.
Nous avons donc 21 dépêches pour 37 moules, soit 0,57 dépêches par moule. Hier, 1303 utilisateurs se sont connectés (sans compter les 37 moules). Sur la même période (2009), ils ont proposés 435 dépêches, soit 0,33 dépêches.
> ce lien n'est plus présent nulle part sur le site
Si, il est dans le plan du site : http://linuxfr.org/plan/ mais c'est vrai que l'on ne le met pas en avant.
[^] # Re: Ah la moderation
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 10.
C'est une dépêche et pas un journal, sinon le problème ne se poserait pas.
> Les moderateurs ont vraiment fait un travail pitoyable
La critique est facile, surtout quand on ne sait pas le travail de relecture et de modération qu'il y a eu. La dépêche est loin d'avoir fait l'unanimité chez les modérateurs, et elle est restée pendant plusieurs jours dans un status quo. On a fini par l'accepter pour diverses raisons plus ou moins bonnes, parce qu'il fallait bien prendre une décision à ce sujet.
> ce n'est qu'un ramassis d'invectives vues d'un seul cote
Certes. Si tu veux nous éclairer sur l'autre coté, n'hésite pas à proposer une dépêche.
> par un compte cree il y a 2 jours et qui n'a jamais rien poste d'autre d'ailleurs
Oui, c'est courant que des personnes créent des comptes juste pour proposer une dépêche et répondre aux commentaires dans cette dépêche. Heureusement d'ailleurs qu'ils le font, parce que les utilisateurs de longue date proposent de moins en moins de dépêches, mais écrivent de plus en plus de commentaires aigris.
En fait, l'équipe de modération est même un peu plus tolérante avec les nouveaux afin de ne pas les décourager dès le début. On n'accepte pas n'importe quoi pour autant et, encore une fois, pour cette dépêche, ça a été très limite.
> cela veut dire admettre un nombre incalculable de conneries.
Pour autant que je sache, ce ne sont pas des conneries, même si je reconnais que c'est présenté d'un point de vue biaisé.
> j'esperes que c'est pas le manque de news qui vous a incite a accepter ce torchon.
Malheureusement, si, ça a joué. Depuis le début de l'année, nous sommes dans une période creuse et nous sommes donc un peu moins regardant sur les dépêches. Nous n'acceptons pas n'importe quelle dépêche, mais si ça continue, ça va être vraiment difficile pour LinuxFr.
[^] # Re: Et lisp ?!
Posté par Bruno Michel (site web personnel) . En réponse au journal Le langage C serait redevenu le langage le plus utilisé. Évalué à 7.
# Pour github
Posté par Bruno Michel (site web personnel) . En réponse au journal Le langage C serait redevenu le langage le plus utilisé. Évalué à 5.
Pour ceux qui sont intéressés par les stats de github, la page http://github.com/languages donne le classement des langages pour les dépôts github. Ça représente 280 000 dépôts (380 000 en comptant les forks) d'après http://github.com/blog/620-committing-like-crazy . Le podium est alors composé de Ruby, Javascript et Perl.
Je n'ai pas trouvé les stats de bitbucket, mais j'imagine que Python doit y être le grand gagnant.
[^] # Re: et les serveurs alors ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un combat de clients de microblogging. Évalué à 3.
[^] # Re: Tweetdeck
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un combat de clients de microblogging. Évalué à 2.
[^] # Re: Gwibber est lent
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un combat de clients de microblogging. Évalué à 3.
[^] # Re: et les serveurs alors ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un combat de clients de microblogging. Évalué à 6.
Ça pourrait être très intéressant. En tout cas, moi, j'aimerais bien lire des choses sur ce sujet, mais je n'ai pas encore pris le temps de chercher des infos sur ce sujet. Donc, si tu connais bien le sujet ou que tu es prêt à y passer un peu de temps, je t'en prie, fais nous une jolie dépêche sur le sujet.
Je rappelle que pour proposer des dépêches, ça se passe toujours sur http://linuxfr.org/submit.html .
[^] # Re: Ruby, c’est fini.
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Le point sur les avancées de Google Go. Évalué à 1.
# Un article sur Go
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Le point sur les avancées de Google Go. Évalué à 5.
[^] # Re: Simplement avec rubygems
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Codez avec classe grâce à Sinatra. Évalué à 5.
[^] # Re: le mouvement NoSQL ...
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 5.
Tu t'appuies sur quoi pour dire ça ? Si ce sont des micro-benchmarks à la shoutout, ça ne veut rien dire (cf http://shootout.alioth.debian.org/flawed-benchmarks.php ).
> Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain.
Moi aussi, mais avant d'en arriver là, il aura fallu coder pendant des dizaines d'heures. Et coder avec des langages dynamiques va généralement bien plus vite qu'avec des langages statiques. Quand je fais du développement web, je préfère la vitesse de développement aux performances.
> Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.
Je développe également des applications Rails. Certaines d'entre elles font des millions de visites par mois, tournent sur un seul serveur dédié et le goulot d'étranglement n'est jamais Ruby mais la base de données.
> Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)
Ouais, c'est connu, les programmes en haskell, ça court les rues. Le seul programme en haskell que je connais, c'est darcs, et il est connu pour deux choses : être le meilleur DVCS sur le papier, et avoir des performances qui varient entre le meilleur et le pire sans que personne ne sache trop pourquoi.
[^] # Re: le mouvement NoSQL ...
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 3.
De mon expérience, compiler et lancer des tests sur un projet prennent souvent un temps comparable.
Sinon, concernant le typage statique, je considère que c'est une forme de tests que l'on t'oblige à écrire. Mais je considère que ce sont des tests assez mauvais et quitte à passer du temps à écrire des tests, je préfère en écrire qui soient pertinents. Par contre, le typage statique a un effet de bord très intéressant : les performances.
Pour le développement d'applications web, les performances sont souvent une considération secondaire. On cherche plutôt la vitesse de développement, et là, les langages dynamiques sont souvent très efficaces. Et le typage statique n'apporte souvent pas grand chose en terme de fiabilité, car une très grande partie des objets manipulés sont de toute façon des chaînes de caractères.
[^] # Re: ???
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche 20 étudiants pour travailler sur Ruby cet été. Évalué à 8.
Enfin, je vais quand même répondre : Ruby et Python sont deux langages très proches, mais ils ne sont pas pour autant totalement équivalent. Par exemple, je vois au moins un domaine dans lequel Ruby excelle et Python est à la traine : l'écriture de Domain Specific Language. Cette force permet à des bibliothèques Ruby de devenir des références dans leur domaine au point d'être copié dans dans de nombreux langages, mais jamais de manière aussi élégante. C'est le cas de Sinatra[1] dans le domaine des API Rest, de rspec[2] pour le Behaviour Driven Development ou de Chef[3] pour l'automatisation de l'infrastructure.
[1] : http://www.sinatrarb.com/
[2] : http://rspec.info/
[3] : http://www.opscode.com/chef
On pourrait également retourner la question. Je serais curieux de savoir quels sont les points où Python brille et où Ruby n'est pas la hauteur. Le support de Google, ça ne compte pas ;-)
[^] # Re: le mouvement NoSQL ...
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 5.
Par contre, tu sembles penser que les langages statiques permettent d'écrire des applications plus fiables. Les études semblent au contraire montrer que le nombre de bugs est proportionnel au nombre de lignes de code et les langages dynamiques permettent généralement d'écrire un même code de manière plus courte. D'autre part, le vrai facteur qui améliore grandement la fiabilité d'un programme est la présence de tests. Les langages dynamiques proposent généralement des bibliothèques de tests bien plus avancées et pratiques à utiliser que celles pour des langages compilés. Mais, au final, peu importe que ce soit un langage statique ou un langage dynamique, un bon développeur écrira toujours du code de meilleure qualité qu'un développeur débutant (mieux testé, et donc plus fiable).
Tu sembles aussi sous-entendre que les "vrais" développeurs utilisent des langages statiques, alors que les langages dynamiques sont tout juste bons pour les scripteurs PHP du dimanche. C'est faux. De très bons développeurs utilisent des langages dynamiques par choix. Il suffit par exemple de regarder les sites à fort trafic pour croiser de nombreux exemples : facebook (PHP), twitter (Ruby), wikipedia (PHP), etc.
[^] # Re: What about CouchDB?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 2.
Si on prend un autre domaine, les files d'attentes, il y a également une forte concurrence entre différents produits. Le gagnant (à mes yeux) est RabbitMQ, qui est également en Erlang. Et pourtant, il y avait une concurrence avec d'autres projets en C (beanstalkd), Java (ActiveMQ) ou Ruby (Starling).