Nathan CrauseMusings of a Software Developer

I found out today that VMWare is going to buy out SpringSource. To be honest, I wasn't even aware that VMWare would be all that interested in a company which provides development and software management tools, but I guess since VMWare is already a player in the cloud computing buzz, they had to come up with something at some point.

Now, the interesting thing here to note that is SpringSource is largely known for it's endeavors into Java-based systems (Spring MVC) and more recently extending that to Groovy and Grails (Grails being based on Spring MVC). One might argue that this means VMWare is backing Java as the path to cloud computing enlightenment.

If VMWare is as big and influential as I think they are, then I think this might be a really important step for Grails, too. It means that the level of corporate acceptance of this dark-horse agile development framework keeps going higher up the food-chain. No disrespect to Ruby and Rails, but I haven't really seen that kind of high-level acceptance within the big corporate guys (yes, I know Amazon has a vested interest, but that's really a minor investment on their part). If VMWare embraces Grails, I think we may begin to see a shift in focus from Ruby on Rails to much more interest in Grails.

This wouldn't really be surprising even without VMWare - Grails has never hidden the fact that it's entirely inspired by Ruby on Rails. However, Grails had the advantage of having a point of reference (Rails) to start with, and could build upon the rather crippling failings of Ruby on Rails:

1. The choice of a new language was a great idea - again, no disrespect intended, but the Ruby language itself isn't very palatable to me as a programmer. Groovy feels more structured, and offers (in my opinion) vastly more freedom to the programmer but remaining completely consistent, where Ruby becomes rather quirky with multiple odd ways of doing the same thing with peculiar syntax. In Groovy, if you want static typing, you can do that. If you want dynamic typing, you can do that.
2. ActiveRecord is terrible. Okay, complete disrespect intended there. It's garbage. It mutually excludes basic Rails from being used in existing infrastructures, and the benefit gained from this is minuscule. Granted, the Rails community right from the start admitted they intentionally sacrificed compatibility with existing structures in order to "simplify" ActiveRecord, but if we look at GORM (Grails' default database layer) it offers the exact same level of simplicity as ActiveRecord, but gives you the freedom to control the structure more fine grained if you choose to. Simplicity at the expense of freedom simply isn't good enough. No large corporation is going to go with a framework which means they have to migrate multi-terabyte databases simply to cater for a quirky database framework - and one which ignores basic normalization rules to boot.
3. Making Grails run inside a Java container might seem like a bad idea, but it's definitely not. Java application servers are incredible beasts. They can easily handle huge amounts of requests, can manage resources easily, beautiful multi-threading. By contrast, Ruby on Rails still runs using some web server module like FastCGI, or multiple instances of Mongrel servers. This is a hideous model. Ultimately, it's required, since Rails was never designed to be thread-safe (nicely done there, boys), and Ruby's threading is slow, and when exceptions occur the backtrace produced is meaningless.

Given all these points, it was probably a safe bet for VMWare to enter this level of product offering using what SpringSource has to offer. They gain a very mature and stable Java-based platform and a fast maturing agile development framework.

Of course, businessmen are known for being able to mess a good thing up, so we'll wait and see.