Pour savoir si Ruby on Rails est prêt pour l'entreprise, il faut réfléchir à ce que signifie le terme "entreprise". D'après mon expérience, entreprise signifie "sûr". Les entreprises qui recherchent une solution d'entreprise choisissent généralement une pile technologique soutenue par de grands fournisseurs. Elles savent ainsi qu'elles pourront bénéficier d'une assistance et probablement de conseils en échange de grosses sommes d'argent. C'est l'approche "personne n'a jamais été licencié pour avoir acheté IBM".
Un autre facteur à prendre en compte est l'ubiquité. Il ne fait aucun doute qu'à l'heure actuelle, Ruby est encore considéré comme un langage quelque peu exotique, ce que reflète la disponibilité de programmeurs Ruby qualifiés. Techniquement, Ruby es plus sophistiqué que Java ou C#, étant plus proche de Smalltalk en termes de pureté OO et plus proche de LISP en termes de facilités de méta-programmation. Il suffit de dire que les entreprises trouveront plus facilement des programmeurs Java ou .NET à bas prix chez les carrossiers que des programmeurs Ruby. Il ne s'agit pas d'insulter les programmeurs Java ou .NET, mais plutôt de refléter le fait que de nombreux employeurs considèrent encore le développement de logiciels comme quelque chose qui doit être fait par le soumissionnaire le moins cher, plutôt que quelque chose qui doit être fait correctement. Les programmeurs Java et .NET sont désormais des produits de base et peuvent donc être proposés à moindre coût.
Techniquement, Ruby on Rails peut évoluer tout aussi bien que Java, .NET ou PHP, etc. Les mêmes principes de base s'appliquent : mesurer les goulots d'étranglement, ajuster les requêtes SQL, minimiser les E/S, dénormaliser le schéma de la base de données si nécessaire et utiliser judicieusement la mise en cache, etc. Si vous avez besoin de créer le prochain eBay ou Amazon, vous devez développer et régler à la main votre propre solution, tout comme eBay et Amazon l'ont fait. J2EE a un avantage sur l'intégration des applications existantes, mais ce n'est pas le cas d'utilisation pour lequel Rails est optimisé de toute façon - Rails a pour but de créer de nouvelles applications CRUD.
Il ne fait aucun doute qu'en l'état actuel des choses, Ruby est l'un des langages les moins performants ; de nombreux investissements sont réalisés dans ce domaine, et il faut donc s'attendre à ce que la situation s'améliore au cours des prochaines années, comme cela a été le cas pour Java depuis sa sortie. De nombreux développements intéressants ont lieu dans le domaine des VM Ruby et des alternatives au MRI (Matz Ruby Interpreter). Personnellement, je pense que JRuby est à surveiller. Il est soutenu par Sun (allez savoir pourquoi) et, comme il s'agit d'une implémentation Java de Ruby, c'est un joli cheval de Troie que vous pouvez utiliser pour introduire Ruby dans votre entreprise, via son infrastructure JVM existante.
Je ne pense pas que Rails soit encore prêt pour l'entreprise et, à bien des égards, j'espère qu'il ne le sera jamais. Je n'ai pas particulièrement envie de voir mon framework favori s'enliser dans la médiocrité ou la confusion des choix multi-fournisseurs, comme cela a été le cas dans le monde J2EE. Heureusement, DHH semble déterminé à ce que Rails continue à être un logiciel d'opinion pour gratter sa propre démangeaison, plutôt que d'essayer d'être tout pour toutes les entreprises.
