Monday’s post about a transition from Java to Ruby did trigger a nice discussion, and I wanted to come back on it.
First of all, I want to thank all contributors, both here and on Hacker News - I was afraid to (re-)ignite an already long religion war, and in place got polite and educated comments or advices. Keep it going!
One of the most frequent advice or question was about Groovy and or Grails as “natural” choices coming from a Java background. I both agree and disagree, and wanted to elaborate somewhat on the answers we’ve already given.
The agree/disagree line is essentially about where you are on two axis.
Existing shop vs New shop
Taking technical decisions when you are (part of) an existing company is very different to the situation where you are creating something new. Especially if this “something” is a startup made of a tight group of like-minded people.
As an existing shop, you cannot evaluate a technology only on its own technical merits, however great they may be. You have to take the existing situation into account, and this “situation” is many fold:
- Applications: Your existing applications, whether in development or maintenance
- Tools: The toolset you use, from the IDE to the monitoring.
- People: Your developers skilled in the above.
In those situations, path allowing gradual evolutions will often be preferable. This do not means that you can never change, only that you have many elements to take into account.
Back on the stated “problem”, I think that Groovy is a really great option for existing Java shops that want or need to put some dynamic “salt” in their development. It allows them to decide where and how to apply this, it can be done on existing applications and keeping the same set of libraries and tools – which are one of Java strongest points in my opinion.
Pick a language vs Pick a platform
Picking a platform means of course a language and running environment, but also tool (including the IDE), libraries ecosystem and (perhaps more important even) a community. Forums, blogs, advices, opinions, documentations, wars and others. This is way more than just a language.
Again, if you have a pre existing investment on any given platform, let say the JVM, when picking a dynamic language, you would be well advised to choose one that can run on it, making the transition much more easier (hey, it’s a war, your release team already knows how to deploy those!). Fortunately, you do not exactly lack choice.
Reciprocally, picking Scala (for example) is not just a language choice. It’s also a platform choice (the JVM or the CLR in this case).
As a final (for now) note about Groovy, I think it is a fine language, and from my very limited exposure to it, Grails looks like a very nice framework. But even with qualities going over being just “A Rails-like framework running on the JVM”, I do not think its ecosystem and community to be on par with the one of Rails (based on a very detailed survey involving subjective experience and random google queries). It is by no means a judgement on quality, just something that matters to us for reasons evoked before.
To come back to our own situation, I may have personally a Java background, but at the moment we evaluated Python/Django and Ruby/Rails, 8th color was certainly not a Java shop – it was going to be what we decided to make it. With quite diverse backgrounds (yes, you can have “diverse” background with only two people, especially if one of them is Christophe), it was really about picking the right platform for us and for Sybil, without any “existing situation” (outside of our existing set of skills).
We did go for Ruby and Rails (and RSpec, d3, Antlr, Grit, jQuery, Sprocket, Saas, Capistrano and many others), and are quite happy with our choices so far.
We are developing an Automated code reviews for Ruby developers using Github, discover how you can become a better Ruby developer.