I'm currently using Groovy on a work project but I'm also learning Scala on my spare time.
My general impression is that Scala still has a bit in its libraries to be ironed out but seems very promising. Scala's concept of "Actors" from Erlang is pretty cool for making concurrency simpler. I'm currently wondering what's to stop Groovy from implementing them though.
I've been playing around with Scala for a few months now. I haven't done any work with Groovy.
I'm not sure what definition of "scripting language" is being used here, but I'm positive I wouldn't consider Scala a scripting language. It's as much of a full-fledged programming language as Java. With a much richer (and potentially complicated) static type system than Java.
As for the libraries, there is some work to be done especially on the documentation. My sense is that most of the Scala libraries are there to support the functional features of the Scala language. However since Scala can painlessly interact with Java, (as can Groovy) there's usually no problem with finding a library to suit any use-case. For instance Strings in Scala are all java.lang.String with can be implicitly converted to a Scala RichString to add additional functionality.
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
JavaOne had a Battle of the Scripting Languages session with Groovy, Scala, Jython, and JRuby. They made a point near the beginning that Scala didn't really belong because it wasn't a scripting language.
The weird thing though is that you can write scripts with Scala and in this respect it seems just as much a scripting language as Groovy.
The implicit conversion thing I learned about recently and I'm glad you mentioned it the way you did. I've been a little disappointed that I can't monkeypatch new methods onto classes like I can in Ruby... and even Groovy's way of adding methods is really weak unless it's in the middle of a script because of classloader issues.
Anyway, I never thought of using the implicit convertor ability to basically mimic monkeypatching. That's really slick, Garrett.
I have to admit, Scala's implicit conversions kind of creeped me out at first. They seemed a little too powerful and too "under-the-hood". As I've worked with them more, I can see the usefulness of being able to add additional functionality in a highly scoped manner.
I have never used any of these libraries, so I cannot vouch for them.
We do a lot of groovy development where I work. There are two developers that I know of that are currently investigating Scala. We have some performance issues that we believe could be solved best with concurrency.
I plan on bringing these groovy libraries to their attention.
Also, while I was in Seattle last summer, I saw a presentation on Kilim (http://www.malhar.net/sriram/kilim/) which was a project to bring erlang-like actors to java. I don't know the status of this project either, but it might be worth checking out if it is still alive.
I think it says much about the power of Scala if the inventor of Groovy himself, James Strachan, writes something like this in his blog:
I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
I personally don't like dynamically typed languages very much, so I'm probably too biased to give a fair answer which one to choose. Anyway it surely has to do a lot with personal taste to choose between a dynamically and statically typed alternative. For this most discussions starting with "X vs. Y" are pointless. You should just give both languages a try and decide yourself. Moreover there's probably no programming language which fits perfectly for all kind of programming tasks or problems.
Moreover there's probably no programming language which fits perfectly for all kind of programming tasks or problems.
Good point Marco.
I am using Groovy. It came about this way. I developed some Java code that processes financial transactions. The users said "that's great, but we don't want to run it from the command line, we want a browser interface". Damn. Developing web apps is so time consuming! I really did not want to grapple with Spring + Hibernate + Ajax + etc. etc. so looked for some frameworks that make web development easy.
Groovy and Grails has worked very well for me. The grails framework provides a very simple web programming by convention approach. Groovy keeps the controller code simple (although I can use Java when I want to). The controller logic is very thin, so the Groovy code in the controller calls out to Java code to perform the actual real (value-added) work.
The groovy/grails solution has worked very well for my particular case (in this instance).
Pick the "tool" you are most comfortable with to solve your particular problem.