Au final tu cantonnes toi même Ruby à un petit marché
Vilain fredix, arrête de cantonner Ruby, s'il te plaît.
La difficulté de maintenance et d'évolution [...]
Rails facilite la maintenance et l'évolution de la même manière que le développement. Ses atouts qui rendent le développement rapide rendent également la maintenance et l'évolution relativement aisés. Je parle d'expérience, pour avoir dû gérer un projet dont le cahier des charges évoluait de jour en jour, de façon parfois drastique.
En fait, je dirais même que Rails est plutôt destiné aux projets qui ne sont pas bien définis ou qui vont beaucoup évoluer. De même que Ruby est surtout efficace pour prototyper rapidement une application, au détriment de la rapidité d'exécution.
En entreprise il peut y avoir d'autres sortes d'utilisateurs : des grosses applis internes (banques, assurances, etc.) qui demande des architectures N-tiers parfois avec de hautes performances.
En entreprise, il peut y avoir des besoins forts en termes de performance. Il peut aussi y avoir des besoins forts en terme de rapidité de développement et d'évolution. Qui a dit que les mêmes outils devaient servir dans tous les cas ?
Les cas où Rails est trop lent et où il est le facteur limitant sont relativement réduits: jusqu'à quelques centaines d'utilisateurs concurrents, un gros serveur bien configuré n'aura pas vraiment de mal. Un bon serveur a un coût négligeable pour une entreprise qui a plusieurs centaines d'utilisateurs concurrents. Et multiplier les serveurs est un bon moyen de monter en charge tout en améliorant la fiabilité. Alors, certes, gérer des millions d'utilisateurs concurrents (la précision est importante) est peut-être difficile en Rails, mais ça représente une portion infime des besoins des entreprises.
Je n'essaye pas de dire que Ruby et Rails sont des outils universels, mais je pense qu'il est vraiment simple d'identifier quand un projet sera trop lourd pour cet outil, et que dans les autres cas, lorsque c'est possible, on gagne à l'utiliser.
[^] # Re: air de déjà vu
Posté par Yusei (Mastodon) . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 2.
Vilain fredix, arrête de cantonner Ruby, s'il te plaît.
Rails facilite la maintenance et l'évolution de la même manière que le développement. Ses atouts qui rendent le développement rapide rendent également la maintenance et l'évolution relativement aisés. Je parle d'expérience, pour avoir dû gérer un projet dont le cahier des charges évoluait de jour en jour, de façon parfois drastique.
En fait, je dirais même que Rails est plutôt destiné aux projets qui ne sont pas bien définis ou qui vont beaucoup évoluer. De même que Ruby est surtout efficace pour prototyper rapidement une application, au détriment de la rapidité d'exécution.
En entreprise, il peut y avoir des besoins forts en termes de performance. Il peut aussi y avoir des besoins forts en terme de rapidité de développement et d'évolution. Qui a dit que les mêmes outils devaient servir dans tous les cas ?
Les cas où Rails est trop lent et où il est le facteur limitant sont relativement réduits: jusqu'à quelques centaines d'utilisateurs concurrents, un gros serveur bien configuré n'aura pas vraiment de mal. Un bon serveur a un coût négligeable pour une entreprise qui a plusieurs centaines d'utilisateurs concurrents. Et multiplier les serveurs est un bon moyen de monter en charge tout en améliorant la fiabilité. Alors, certes, gérer des millions d'utilisateurs concurrents (la précision est importante) est peut-être difficile en Rails, mais ça représente une portion infime des besoins des entreprises.
Je n'essaye pas de dire que Ruby et Rails sont des outils universels, mais je pense qu'il est vraiment simple d'identifier quand un projet sera trop lourd pour cet outil, et que dans les autres cas, lorsque c'est possible, on gagne à l'utiliser.