Groovy / Grails :: Ruby / Rails :: 2011 Etat du cadre

Question

Oui, similaire à plusieurs threads, mais nous sommes maintenant en 2011, et beaucoup de choses ont changé.

Graal 1.3.6 a amélioré considérablement par rapport à la v1.3 quand j'ai d'abord essayé d'apprendre le framework (et a donné jusqu'à ralentir les temps de compilation et d'autres gémissement induisant des événements).

Après avoir passé quelques mois avec la dernière version, je suis impressionné, protyping une application est un absolu brise (GORM est grand!). Le mode de développement que l'on n'a plus besoin de redémarrer, sauf les changements de classes du domaine. Groovy.lang est fantastique (bare à l'esprit, c'est par rapport à mon travail de jour la vie en PHP).

Maintenant, sur le revers de la médaille, il est Ruby/Rails, j'ai peu d'expérience avec l'au-delà parcourant Ruby docs et l'exploration Active Record (à comparer à GORM). Venant de PHP/Jquery, groovy, la syntaxe est du gâteau, ruby pas tellement, bien qu'accessible.

Ruby/Rails est à la mode, tandis que Groovy/Graal semble prendre de la vitesse dans son propre droit.

J'aimerais entendre ce que les deux camps ont à dire (flamme induisant lang guerre de bienvenue): les avantages/inconvénients des deux langs/cadres de 2011. Lors du choix d'un cadre, il est important de savoir ce que vous obtenez en, alors allez-y, débutants bénéficieront, et les experts peuvent évent ;--)

Answer 1

Rails et de Grain sont à la fois d'excellents cadres avec leurs versions actuelles. Vous ne pouvez vraiment pas vous tromper avec. Voici quelques choses que je trouve intéressantes à leur sujet:

Rails

• Rails (Ruby), ne l'est pas ainsi que le Graal (Groovy). Vous aurez besoin de plus de puissance pour exécuter votre application. Ce n'est pas une grosse affaire à tous avec le PaaS, comme les options de EngineYard (et, espérons le, une AWS BeanStalk Rails option dans le futur), mais il peut coûter un peu plus pour exécuter une application Rails vs un Graal application (évidemment JRuby est également une option si).
• Rails est un peu mieux avec NoSQL alternatives actuellement, mais Graal est en train de rattraper rapidement
• Rails a beaucoup plus de plugins, mais cela peut conduire à des problèmes si vous utilisez certains qui ne sont pas entretenues (beaucoup d'entre eux n'ont pas actuellement de travailler avec Rails 3, mais soit).
• Rails est plus mature et a plus de fonctionnalités à ce point dans le temps, car il a été autour de plus
• Rails de REPOS support est incroyable
• Il y a beaucoup plus de "gros" Rails de sites que de Graal
• Ruby est beaucoup plus populaire que Groovy - TIOBE
• Pas de dépendance sur Oracle, ha! (Graal a bien besoin de la JVM)

Graal

• Graal s'intègre avec la JVM de mieux que de JRuby
• Graal GORM est mieux que ActiveRecord (à mon humble avis), bien que les Rails de 3 a ouvert la porte un peu pour les autres persistance d'options, mais tous les livres, tutoriels, etc tous les utiliser ActiveRecord
• Graal Vue taglibs sont mieux que <=%...%> en vue
• Graal, les plugins sont bien documentées et clairement indiquer s'ils sont pris en charge par SpringSource ou pas
• SpringSource investit massivement dans le Graal
• Il y aura beaucoup plus de l'entreprise des emplois pour Grain de les Rails dans le futur, mais plus startups utiliser Rails (où voulez-vous travailler?)

Mon point de vue

• J'ai utilisé des Rails il y a quelques années, je travaille sur un projet Graal
• Je les aime mieux que Django (Python) ou Zend Framework (PHP)
• J'ai l'intention d'apprendre l'Ascenseur (Scala) suivant

Ma Recommandation

• Si vous n'avez jamais fait de développement Java et travaillent sur un projet pour une petite ou moyenne site, d'aller avec des Rails
• Si vous travaillez dans une grande entreprise qui utilise Java, essayez de tangage Graal pour votre gestion de la "prochaine Java cadre" ils devraient investir dans
• Si vous travaillez sur "le prochain twitter ou foursquare," eh bien, alors vous êtes assez intelligent pour répondre à cette question vous-même! :)

Answer 2

Première fois que j'ai commencé un projet avec des Rails, j'ai été vraiment surpris:

• Comment puis-je séparer le "référentiel" de "Service"? Oh mon Dieu: je dois mettre de la logique métier des contrôleurs... je ne peux pas imaginer un vrai gros projet avec Ruby on Rails: Est-il Quelqu'un sur 37signals de rappeler les principes de base de la séparation des Affaires de Domaine et/Référentiel. Les Rails dossiers/les classes de la structure n'est pas prendre soin à ce sujet.

• Deuxième chaussette: "Active Record". Essayez de concevoir un véritable complexe Orientée Objet de la couche de gestion et la carte en utilisant les Rails Modèles (Active Record)... vraiment: ne pas.

• 6 mois plus tard, avec notre projet en cours d'exécution: R&R consomme 80% de CPU (et de mémoire...) à l'aide d'apache + passanger sur un serveur quad core... et le Postgresql Base de données est en vacances (3 à 4% de CPU)... Oh mon dieu (nouvellement)

  Mon vieux ASP/VB6 applications où l'capable de servir des pages à 300 utilisateurs simultanés dans un réel backoffice contexte réel des bases de données complexes et complexe installé sur un appareil autonome (une année 2001 1 CPU serveur de base).

Bien sûr, des conventions et de la syntaxe Ruby sont belles... et personne n'a besoin d'un compilateur (... tests unitaires sont utilisés pour cette porpouses 90% du temps... juste pour résoudre le disparu de taper à chaque fois que je change un peu de code... "s'il vous Plaît, la programmation de dieu, de prendre soin de mes doigts erreurs" )

Première impession avec Graal:

• Un "Cool" de la pile inspiré sur des Rails avec des professionnels de l'alimentation basé sur le framework Spring (Cio, Hibernate, ...)

Et OUI!!!

• Il est propre Domaine/Service de la séparation. NICE!!!
• Vous pouvez, éventuellement, oubliez Java.

Answer 3

Rails est assez mature, a un ÉNORME écosystème pour aller avec elle. Je ne suis pas familier avec le Graal ou de soutien en ligne, mais le drapeau rouge, je vois dans votre post, c'est que vous avez admis Graal est en train de rattraper Rails.

Ruby est un vrai bonheur de travailler avec (et cela vient d'un vieux C++ hack... pourquoi, de retour dans la journée, j'ai utilisé de programme avec juste un clavier hex, les jeunes whippersnapper... maintenant GET OFF MY LAWN!).

Il y a des choses à propos de ruby qui font qu'il est difficile de suivre à la fois (method_missing je suis à la recherche à VOUS), mais je suis sûr que peut être dit à propos de n'importe quelle langue.

Moi? J'irais avec ruby et rails.

Answer 4

Bien pour les Grails, je pense toujours que même en rattrapage, il y a 2 choses principales que les rails n’auront pas de manière simple:

• mise à l'échelle
• des tonnes de bibliothèques Java matures à portée de main (personnellement, géotools, entre autres)

Answer 5

Ruby on Rails est remarquable - comme le Pink Floyd de web dev.

Groovy sur le Graal est un bon exemplaire - un peu comme l'Australian Pink Floyd show...

BTW - Nous avons à la fois au travail et je l'ai vu de nombreux Graal développeurs finissent par apprendre les Rails et le bâton avec elle.

J'ai vu aussi des Rails les développeurs apprennent Graal, mais AUCUN d'entre eux ont préféré.

Environ la moitié du temps, nos développeurs Java apprendre Graal et tout simplement rester loin de Ruby.

À mon humble avis - Si vous avez réellement connaître les deux assez bien, vous aurez presque toujours eu une préférence pour Ruby et Rails.