Looks like Groovy is going to loose its steam.
Two reasons: tooling and governance.
Tooling is a critical element as the code base and number of involved engineers increase. Refactoring in a single code base which involves a dynamic language and dozens or hundreds of engineers may lead to hairy situations. When you change a public library API in Java your tool will let you know where is the effected code, update the references for you and will let you know if a contract is getting broken. Tests should locate problems created by refactoring, but:
- Groovy engineers (and not only them) are sometimes too cool to do a 100% code test coverage.
- Even a 100% test coverage can not guarantee that there are no bugs, it can only confirm that the test code didn't find bugs.
public int getProductID();to:
public ProductID getProductID();
So if you have a method in your Groovy shopping chart that gets a productId and compares it to a local product id it will not break the code. I.e., no method names where changed and the compare with int and object will simply return false. If the method is rarely used and not tested, or tested only in a way that supposed to return false then you won't find it before your user, and they always find these things.
Prime large scale products can not afford this.
Most of the claims I heard for having dynamic typing is for cleaner and smaller code. Yes, you may have strong typing in Groovy if you wish, but then your back to ugly Java code. With the amazingly comfortable type inference in Scala, you enjoy both words.
The second reason is governance. Both Groovy and Scala are still in the youth where the Cathedral model is the only way for them to react fast and efficiently enough to feedback from the market. Unfortunately Groovy is JSRd. On its face it looks good, hey - what's wrong with Democracy? Well, it appears that its not the best way to run an engineering project and in some case it locks the product in infinite politics games and narrow interests of the few in charge.