TIOBE and Groovy and Grails random thoughts

November 13, 2008

So having recently launched a magazine on the Groovy language, I decided to check out the TIOBE index and see where Groovy sits.  Not terribly high (#41) but not too bad for a relatively new language.  Certainly higher than many others with much longer pedigrees.  The TIOBE index also has a couple other interesting notes:

• The trend for the last year for dynamic languages (vs statically typed languages) has gone down slightly. 
• Perl is at an all-time low

Not much to do with me really, I was just somewhat relieved to see Perl start slowing down.  Yes, it’s going to be around for a long time, and yes, it’s powerful and CPAN has functionality to do everything except take out my garbage.  It’s just a difficult language for me to be productive in.  Always has been, likely always will be.  So, to the extent that alternatives make headway against Perl, I’m happy.  :)

How does all this affect Groovy?  Groovy is a unique beast, being able to be statically or dynamically typed, and compiling down to Java.  Many fans are eager to say Groovy *is* Java, but can be more if you want it to be.  Groovy brings the power of Java to the ’scripting world’, and brings the power of scripting to the Java world, yet even that nifty phrase feels like it’s shortchanging Groovy some.

G2One, a consultancy based around Groovy and Grails (founded by the project leads of both Groovy and Grails) was recently acquired by SpringSource.  SpringSource is a consultancy and product development company built around the Spring framework.  I have to admit, not coming from a Java background, I still don’t 100% grasp how Spring fits in to the Java ecosystem, but I’m learning fast.  The shorthand version I’m getting from people is that the Spring framework simplifies Java development.  Anything that simplifies Java development is good in my book, but it apparently didn’t go far enough, because Grails seems to simplify Spring development, by bringing a standardized approach to web development and building on top of the Spring framework where appropriate.

I suspect that the acquisition will see a tighter integration of more Spring framework functionality in to the Grails framework.  It’s too early for me to say whether that would necessarily be a good thing.  Frankly, as a primarily non-Java person looking at the web development world in Java, the no-nonsense Grails approach has been much more productive for me than anything else (and I’d looked and tried out multiple web approaches in Java before discovering Grails).

SpringSource has an application server which looks to be a bundle of a modified Tomcat system and the Spring framework.  I installed it, and there seems to be less server management functionality than even a base Tomcat gives you.  From a ‘bloat’ standpoint, perhaps that’s good, but it seems to me that there’s still work to do to address the needs of the small web hosting business.

Why address those needs?  Because that’s where many businesses start off.  Many of the ‘enterprises’ of tomorrow will start with modest shared hosting accounts today.  Right now, it’ a PITA to have a Java web app (and specifically a Grails app, but others as well) live at the root of a domain.  It’s very easy to have “http://domain.com/myWebApp/” but harder to have “http://domain.com/” point to a standard WAR file.  Tomcat lets you do this once per server instance by specifically naming your WAR file “ROOT.war”.  Totally ridiculous, imo, and we need a Java hosting system that can manage mappings between virtual hosts and application installations (if only WAR files).  

“But Java is for enterprise applications” many Java die-hards will be thinking.  That’s only because it’s ceded the low-end hosting space to PHP and others by default, not because of any long-term strategy.  I’ll reiterate – this is important to Java’s long term future in the web world (and what part of the software space isn’t web-related?).  Smaller companies (which often grow in to larger companies later) will make their decisions based on a number of factors, but hosting support is one.  Developer availability is another, and developer familiarity with hosting options plays a part in what those developers end up devoting time to learning.

Virtualized servers solve the problem to some extent, but it’s the virtual host mapping which makes LAMP-style servers attractive to many people.  Multiple domains, all with root-path goodness, on one server with multiple discrete directories hosting various code.  I realize I’m harping on this over and over, but it’s been shocking to me how poor the support for this sort of thing is.  No decent interfaces, no way to delegate this sort of management to anyone except a server admin who has to futz around with multiple XML files on a server.  This went out of fashion in the LAMP world about 10 years ago, and I believe played no small part in the fast adoption rate of LAMP applications as the dominant face of public web applications.

Have I missed something?  Is it so simple to do this that no one even bothers to write about it because everyone ‘knows’ how to do it?  Or is this another area of Java which people have quietly abandoned (like cross-platform desktop multimedia).  To the extent that Sun is renewing their efforts behind JavaFX, we may see some traction for desktop Java again.  I’d like to see them (or anyone) make the same commitment to low-end Java hosting.

SpringSource, with its Grails acquisition, may be in a good position to address the needs of this market, helping to nurture a next generation of Java developers getting their first start with Java on Groovy and Grails web applications.  I’ve no idea if this is in their plans, but it doesn’t seem out of the realm of possibility.  Or does it?  Am I barking up the wrong tree?  Or just barking?  ;)

Posted in Development, Grails, Groovy, Java, Software