Andres is a DZone Zone Leader and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Alex Tkachman on Static Groovy: the inside scoop

02.02.2010
| 21459 views |
  • submit to reddit

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).

Published at DZone with permission of its author, Andres Almiray.

Comments

Dean Del Ponte replied on Tue, 2010/02/02 - 8:06pm

Groovy is not very slow at runtime.  That statement by Alex is is a bit misleading.  Groovy is on par with other dynamic languages (Ruby, PHP, Python).

Johan Lund replied on Wed, 2010/02/03 - 3:29am in response to: Dean Del Ponte

I believe he was comparing it to Java.

Ricky Clarkson replied on Wed, 2010/02/03 - 3:39am

Groovy is not slow compared to other slow dynamic languages, you mean. Lisp, Smalltalk and probably even Erlang and JITted JavaScript trounce it.

Artur Biesiadowski replied on Wed, 2010/02/03 - 5:14am

Plain groovy being 8-12 times slower that java is very conservative estimation. In pure language/runtime benchmarks (not something I/O, DB or native-method bound) it is around 300 times slower (on server jvm after warmup).

From what I have seen with groovy++ so far, it has chances of reaching java-like speed - so I think that benefits of groovy++ are actually underplayed here. Remember, worse you present plain groovy, better groovy++ appear in comparison :)

Alex Tkachman replied on Wed, 2010/02/03 - 5:23am in response to: Artur Biesiadowski

Artur, I am core developer of groovy and spent (and continue) huge amount of time making it better. I have zero intention to present plain groovy in bad light. Groovy is great dynamic language. Groovy++ is attempt to create statically typed story for it. Alex

Mark Haniford replied on Wed, 2010/02/03 - 11:08am

Besides the massive speed increases with static Groovy, eventually you'll be able to get all the IDE refactoring and code-completion support that Java now enjoys and that is sometimes impossible in a purely dynamic language like Groovy.

Otengi Miloskov replied on Wed, 2010/02/03 - 2:29pm

The thing is that the author said he wants Groovy static for calculations, concurrency and distributed but why all this effort if Scala already does that and much more.

I belive in the right tool for the job, Let Groovy for scripting and Scala for the heavy and fast work. Scala is also a modern language with lots of OOP/FP concepts, not verbose and much more.

IMHO having Scala, groovy++ it is pointless.

 

Andres Almiray replied on Wed, 2010/02/03 - 2:49pm in response to: Otengi Miloskov

As pointless as it is for Ford to produce Fusion when Toyota's Camry is clearly better. Right. Both cover the same needs but with different design choices and implementations. Same thing with Scala and Groovy++. And if you've follow Tim Bray's blog you'll notice that Clojure smokes Scala in some areas. Is it pointless to develop Clojure too?

Cre The replied on Wed, 2010/02/03 - 4:09pm in response to: Otengi Miloskov

Agreed with Andres. Does scala play well with a java environment? Doesn't competition breed quality?

Ronald Miura replied on Wed, 2010/02/03 - 8:56pm in response to: Dean Del Ponte

Groovy is not very slow at runtime. (...) Groovy is on par with other dynamic languages (Ruby, PHP, Python).

In other words, "Groovy is very slow at runtime, just like other dynamic languages (Ruby, PHP, Python)" :)

Otengi Miloskov replied on Wed, 2010/02/03 - 11:21pm in response to: Andres Almiray

Im fan also of Clojure, Haskell, Ocaml by the way. But Scala or Clojure ware designed from the start for speed and concurrency/distributed but Groovy was just designed to be a cool dynamic scripting language.

The problem of this kind of aproach, you end with a Frankeisten language and not designed for what it was to be.

My point is Groovy is just fine as a dynamic scripting language yes is slow but it just works for what the poeple choose groovy to use but if continue ahead to this aproach it will become a complicate frankeisten language that later nobody wants to touch and I will have another language to rant.

Cheers.

Sean John replied on Thu, 2010/02/04 - 6:24am

Will it ever be possible to catch errors at compile time? This is one of the things everyone writing scripts should want.

Alex Tkachman replied on Thu, 2010/02/04 - 8:11am in response to: Sean John

Groovy++ does catch compile time errors

Jeff Gortatowsky replied on Thu, 2010/02/04 - 12:54pm

groovy++ is not pointless in light of scala. Why learn a completely new language if you have one that is near to what you know, and provides all you need? The wonderful thing about groovy in my mind is it being a more expressive, more agile, Java. Scala is, Scala. Now if I can choose groovy for rapid development and for tasks where it's performance is good enough, and choose groovy (++) for tasks where runtime performance is paramount, why wouldn't I simply choose groovy? Polyglot programming is fine when there is no choice. However given a choice I would stick to one language for a project if that language meets all the development and product goals. groovy and groovy (++) might do that.

Matthew Passell replied on Sat, 2010/02/13 - 7:53pm

Could we please instead call it something like "Static Groovy", "Speedy Groovy", or even "Super Groovy"?  Adding "++" to the end of the existing name brings in so much baggage.

--Matt

Daniel Pfeifer replied on Sat, 2010/04/10 - 4:02pm

This sounds great, any chance this one day could become a part of the standard Groovy distribution? I would love to get a taste of IDE-supported statically typed Groovy with Grails on top :)

Liezel Jandayan replied on Wed, 2012/05/23 - 7:31pm

And the rest of us will happily benefit from the tools and the improved Java frameworks that use this.-Tire Works

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.