est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ?
Aujourd'hui, il existe plusieurs implémentations de Ruby : l'interpréteur C "original" (écrit par Matz, Yukihiri Matsumoto), la machine virtuelle YARV/Ruby2, JRuby, Rubinius, ...
L'interpréteur est assez lent (un petit peu plus que Perl dans les benchmarks). YARV était environ 4 fois plus rapide il y a quelques mois pour mes scripts maison, mais est encore en développement. JRuby est une implémentation complète niveau fonctionnalités, les performances sont équivalentes à l'interprèteur C, et on peut compiler en bytecode JVM (ou utiliser le JIT, voir http://www.headius.com/jrubywiki/index.php/JRuby_Compiler pour plus d'info).
Est-ce que Ruby dispose de nombreux connecteurs ?
Si tu parles des bibliothèques d'accès aux SGBD écrites en C, c'est assez fournit ; Oracle, PostgreSQL, SQLite, ... Avec JRuby, je suppose qu'on peut utiliser JDBC, donc pas de soucis.
Est-ce possible en France de recruter des développeurs Ruby ?
Si l'on en croit http://rubyfr.org/ , ça doit exister... Il y a même une carte de France des rubyistes :-)
<publicité éhontée>Sinon ya moi :-))))</publicité éhontée>
Et surtout, est-ce qu'il y a des retombées commerciales potentielles ?
Je manque de stats sur le sujet, mais je pense que Ruby est un très bon complément au Java (via JRuby), par exemple pour des règles métier complexes et fréquemment mises-à-jour. Ce que je veux dire, c'est que c'est une solution peu utilisée, mais qui a toutes les fonctionnalités de Perl avec une syntaxe objet plutôt agréable, et qui gagnerait à être connue (Rails est l'arbre qui cache la forêt). Les perlistes ne devraient pas avoir trop de difficultés à comprendre un script Ruby (c'était un des buts du créateur du langage).
Pour résumer, je crois que si on peut le faire en Perl, on peut aussi le faire en Ruby : les langages sont assez similaires tant au niveau de l'implémentation (vitesse d'exécution) qu'en ce qui concerne les "cibles" potentielles. Après, c'est surtout une question de goûts (je trouve le Ruby plus lisible, au cas où vous ne l'auriez pas deviné ;-) )
[^] # Re: générer du Ruby
Posté par doupatex . En réponse à la dépêche Talend Open Studio 2.2.0. Évalué à 4.
Aujourd'hui, il existe plusieurs implémentations de Ruby : l'interpréteur C "original" (écrit par Matz, Yukihiri Matsumoto), la machine virtuelle YARV/Ruby2, JRuby, Rubinius, ...
L'interpréteur est assez lent (un petit peu plus que Perl dans les benchmarks). YARV était environ 4 fois plus rapide il y a quelques mois pour mes scripts maison, mais est encore en développement. JRuby est une implémentation complète niveau fonctionnalités, les performances sont équivalentes à l'interprèteur C, et on peut compiler en bytecode JVM (ou utiliser le JIT, voir http://www.headius.com/jrubywiki/index.php/JRuby_Compiler pour plus d'info).
Si tu parles des bibliothèques d'accès aux SGBD écrites en C, c'est assez fournit ; Oracle, PostgreSQL, SQLite, ... Avec JRuby, je suppose qu'on peut utiliser JDBC, donc pas de soucis.
Si l'on en croit http://rubyfr.org/ , ça doit exister... Il y a même une carte de France des rubyistes :-)
<publicité éhontée>Sinon ya moi :-))))</publicité éhontée>
Je manque de stats sur le sujet, mais je pense que Ruby est un très bon complément au Java (via JRuby), par exemple pour des règles métier complexes et fréquemment mises-à-jour. Ce que je veux dire, c'est que c'est une solution peu utilisée, mais qui a toutes les fonctionnalités de Perl avec une syntaxe objet plutôt agréable, et qui gagnerait à être connue (Rails est l'arbre qui cache la forêt). Les perlistes ne devraient pas avoir trop de difficultés à comprendre un script Ruby (c'était un des buts du créateur du langage).
Pour résumer, je crois que si on peut le faire en Perl, on peut aussi le faire en Ruby : les langages sont assez similaires tant au niveau de l'implémentation (vitesse d'exécution) qu'en ce qui concerne les "cibles" potentielles. Après, c'est surtout une question de goûts (je trouve le Ruby plus lisible, au cas où vous ne l'auriez pas deviné ;-) )