Alex Tkachman on Static Groovy: the inside scoop

The notion of an statically typed Groovy has caused quite the waves lately in both Java and Groovy communities. Dzone caught up with Alex Tkachman, project founder and lead, and got the inside scoop on the project. Continue reading to learn more about the project's goals and future developments.

Andres Almiray: There has been a lot of buzz recently about statically typed Groovy. What is it all about?

Alex Tkachman: The idea of a statically typed dialect of Groovy is pretty old. The point is that Java as a language is very verbose and inconvenient for modern applications, especially multithreaded and distributed ones. We need something much more expressive, otherwise complexities of domain area becomes multiplied by complexities of the language.

Groovy is very expressive and at the same time syntactically very close to Java, so the learning curve is pretty flat. Another amazing thing is 100% interoperability between Groovy and Java. A Groovy object is a Java object and vice versa. You can mix Java and Groovy sources in any combinations. You can even compile Groovy and Java together (invention I am personally very proud of) Standard Groovy libraries extend JDK libraries. All together it says that use of Groovy makes your arsenal wider but keep all your previous Java investment.

Andres: Sounds like a traditional Groovy pitch so far, what's the catch?

Alex: In truth it's not a pitch. Groovy is a great language. Unfortunately at the same time Groovy is very slow at runtime. As a person, who did a lot to improve performance of Groovy I can probably speak about that very openly. Groovy is very slow. You can easily expect that some Groovy calculation or data transformation rewritten in Java will become 3-5 times faster. Usually this factor is 8-12 and sometimes even higher. Someone can say that Java is always at our service and nobody uses Groovy for calculations or data processing... But, hey, it is exactly my point - why should we limit ourselves for just scripting or handling of simple web pages?

What is even worse is the fact that Groovy doesn't scale well for multi-core computers meaning that several threads executing code compiled by Groovy really prevent each other from being fast. It is not a problem for many applications but for many others it is simply show-stopper.

Someone can argue that these are just defects of the current implementation, which can be improved overtime. I am not sure it is true. I believe these problems are derived from fully dynamic nature of Groovy. If you need the ability to change dynamically behavior of any call done in any place you have to pay for that. There are laws of nature, which you can not fool. There is always space for more optimizations but there are limits. As all of us know the fastest code is the one whichis never executed.

The good news is that we don't need fully dynamic behavior always. Great syntactical expressiveness plus powerful type inference can do magic with statically compiled code. Here the idea of statically typed groovy comes in to play. Let us separate code which requires high performance from code which requires fully dynamic features. Instead of today's equation Groovy==Expressive && Java==Fast we come to All Code == Expressive & FastAsNeeded.

Andres: Which means that if I want to achieve performance I don't need to put types everywhere like we do in Java?

Alex: Not at all. We are doing a very good job with type inference. In fact, we surprised ourselves in how good we are in this particular area. The general principle here is that developer of API should provide enough type information, which is usually still less than required in Java, and then users of the API need to provide just the minimum, the compiler will deduct the rest.

We get a very expressive language, which is similar and close to Java from one side and from another side, where different pieces of code can enjoy performance and compile-time type checking (critical for integration with existing Java code) and other parts can be fully dynamic. This is the main goal of Groovy++

Andres: Groovy++, is this the official project name?

Alex: So far, yes. It is probably a bit controversial because of old story of C/C++. I believe the main difference is that we don't try to create a new language but use Groovy's self-extending abilities to bring new value in to a great and popular language. Groovy++ is not about replacing Groovy but about enhancing it. Making the Groovy language usable for a much wider range of applications. Enhancing in it a way that it may beGroovy++ the one with the chance to replace Java.

You know, in the Groovy community we never said before that Groovy is here to replace the Java programming language. And this is not because we don't need a better language or Groovy is not good enough. We were not able to say it before because Groovy is slow and does not provide compile time checking. With Groovy++ the game has changed - expressive, fast, both static and dynamic, fully interoperable ... Aren't those the main requirements for Java.Next?

Andres: Is it open source?

Alex: Yes. Well, partly yes already and the rest will be soon. Let me explain. The project consist of two parts - the compiler and a standard library. The standard library is open-sourced already and open-source version of the compiler is coming in next couple of months.

There are two issues here, which prevent us from open-sourcing the compiler immediately. First of all, it uses several pieces of technology, which our company uses and plans to use in our commercial products. It was not critical when project started as experiment but now we need to extract these parts and replace/rewrite with proper open-source alternatives.

The second problem is interesting by itself. We are talking with several well-known vendors about their involvement with the project. There is no much sense in finalizing exact OSS license before these discussions are not completed and we are sure that all interests are well covered. Something interesting is coming and I wish I could tell you more right now.

Andres: Is it a fork of Groovy or an addition?

Alex: God forbid. It is not a fork of Groovy in any sense. Groovy++ is built on top of Groovy 1.8.x branch and just adds one jar file to the distribution.

It was our intention from day one to do everything possible to avoid a fork even if the existing architecture of Groovy compilation is not necessarily optimal for our static compiler. Fortunately, we were able to find all right workarounds and even contributed back a lot of bug fixes especially in the area generics support, which is traditionally not widely used in Groovy.

Andres: How does it work?

Alex: It is unbelievably simple. You just annotate a piece of code (method or whole class or even package statement to cover all classes in the file) with @Typed annotation and magic happens. Thanks to the brilliant idea of AST transformations in Groovy, we can mix statically and dynamically typed code in any combination.

For statically compiled part the compiler does type inference and all necessary checks and generates very fast byte code. For dynamic code it uses normal Groovy compiler, so you can be sure thatGroovy++ will not break your Groovy code.

My personal favorite is the so called mixed compilation mode, where static compiler does the best efforts to resolve methods and properties but if fails to generate dynamic calls. It creates an extremely impressive opportunity of combining dynamic features of Groovy (building markup for example) right with fast calculations.

Andres: Why do you need a special standard library? What's wrong with the one included in Groovy?

Alex: Our standard library is mostly an addition to Groovy's . We need this addition for two reasons: first groovy implemented their services with the dynamic dispatch in mind, which is not true for Groovy++. This does not necessarily entail bad performance, but rather the lack of type information in standard Groovy library which makes it inappropriate for use in a static language.

Second, since Groovy++ yields better performance, it makes sense to provide additional utility classes. For example taking care of scheduling multiple tasks on a multicore machine or providing functional-style operations on collections.

BTW, we are really proud that there is no single line of Java code in Groovy++ standard library. Everything is written in Groovy++.

Andres: What are its current drawbacks?

Alex: So far we found only one small inconvenience - it is not always possible to simply copy/paste code from dynamic block to statically typed one. This is a two way road, so let me explain both directions on the problem. Obviously, a transformation of dynamic code to static one might require some additional type information to be provided. This probably does not come as a surprise. The interesting part is that in some situations, because of type inference, statically typed code requires less type information. For example, 'as' operator is almost never needed for closures. Unfortunately it means that copy/paste from dynamic code to statically typed one might require some additional tweaking. That's pretty much the only problem we've found so far.

Andres: How does it compare to Scala/Clojure?

Alex: Well, both Scala and Clojure are great languages. Period. We borrow a lot of ideas from both. Mostly ideas coming from the world of functional programming. For example, we already support persistent collections introduced in Clojure. Good Scala type actors are obviously in plans as well as Erlang-style supervisor tree. Totally different kind of example is Scala-like traits, which we have already and really enjoy using in standard libabrary.

I would probably need to write several articles comparing Groovy++ with each of these languages/runtimes by features. But the main and probably only important difference is that Groovy++ is very easy to understand for 9 million Java developers worldwide. At least for one developer from these 9 millions, which is myself, both Scala and Clojure are too complicated and too far from Java.

Seriously, flat learning curve, similar syntax and full interoperability makes Groovy++ unique on the very wide landscape of JVM languages.Groovy++ is like onion - you get a 'simple' language on the surface, but you can peel away layers and layers and you get plenty of features

Andres: What is the project's roadmap?

Alex: In next 2-3 weeks we want to release version 0.2, which will have contain fully functional static compiler and then over a month or two to be concentrated on bugfixes, writing samples, documentation and tutorials, which will probably lead us to version 0.5 in April-May. In parallel with that we will work on improving standard library in to direction of better support for multithreading and distributed programming.

We have a lot of ideas in this area - distributed actors and data caching, software transactional memory, erlang-style supervisor trees. It is a bit hard to say right now what should go directly to standard library and what has potential to become separate project or join already existing projects likeGPars. What we are sure about is the fact that combination of expressiveness, performance and compile time checking of Groovy++ can make it a language of choice for coding traditional very complicated problems, to making these problems easier for every developer and not only super stars.

Andres: Are there any plans regarding IDE support?

Alex: You will be surprised but Groovy++ does not require any special IDE support. What I mean is that the existing Groovy support in IntelliJ, which we use, or NetBeans, or Eclipse works pefectly with Groovy++. Compilation, code search, navigation - all things we normally expect. Of course, developers always look for better but I believe the current state is pretty good.

Andres: Do you have any parting thoughts?

Alex: I have a dream that at some day every Java developer will at least consider Groovy++ as option for her or his next project. In the meanwhile I invite everybody to give Groovy++ a try. Have fun, let us know what do you think and what is your expirience .

The open-source part of the project is hosted at Google Code - http://code.google.com/p/groovypptest/ We are still very young and pure in terms of documentation but it is coming. So far the best place to ask questions is small but very friendly community at Groovy++ dicussion group http://groups.google.com/group/groovyplusplus You can meet their both developers of Groovy++ and our first users and even some Groovy rockstars.

Till next time. See you online!

Alex Tkachman is creator and leader of Groovy++ project. Alex is actively involved in to Groovy and Grails community and as developer in Groovy Core team responsible for many performance improvements and language enhancements. Alex also member of GPars development team. In 2007 together with Graeme Rocher and Guillaume Laforge Alex founded G2One Inc., which was later acquired by SpringSource. Before that Alex was COO of JetBrains, the company behind IntelliJ IDEA. Alex's main areas of professional interest are application performance and concurrent and distributed computing. In his day job Alex is partner in MB Technologies, the company behind the popular Bindows AJAX framework (http://bindows.net).