The main goal of Groovy++is that, on the one hand, it is rich in expression and very close to Java; On the other hand, some code blocks can enjoy performance and compile time type checking, while others are completely dynamic.
Is Groovy++the official project name? Is it open source?
yes. Its relationship is a bit like C and C++. We are not creating a new language, but extending Groovy itself to bring new value to the language. Groovy++enhances Groovy rather than replaces it. As we all know, in the Groovy community, we have never said that Groovy replaces the Java language before. This is not because we don't need a better language or Groovy is not good enough, but because Groovy is too slow and cannot provide compile time checks. With Groovy++, everything has changed - expressive, fast, dynamic and static, fully interactive with Java... these are the main requirements of the next generation of Java.
Groovy++is open source. Some are already open source, and the other will soon be open source. The project is divided into two parts: compiler and standard class library. The standard class library has been open source, and the compiler will be open source in the next few months.
The reason why we didn't open source the compiler immediately is that many commercial product technologies are used in it. After these parts are extracted, replaced/rewritten, we can open source. In addition, we talked with several well-known manufacturers about investment in this project, and it is not meaningful to finalize the open source software license before the discussion is completed.
Is Groovy++a branch of Groovy?
Groovy++is not a branch of Groovy, but is built on Groovy 1.8. x, and only adds a jar file to its distribution package. From the first day, we tried to avoid it becoming a branch of Groovy, even though the existing Groovy compilation framework is not optimal for our static compiler. Fortunately, we found all the correct solutions, and even went back to fix the bugs in these methods. These methods are not widely used in Groovy.
How does Groovy++work?
Very simple, just add @ Typed annotation to the code block. The AST transformation in Groovy helps a lot. We can combine static and dynamic type code arbitrarily. For the static compilation part, the compiler performs type inference and all necessary checks, and produces highly efficient bytecode. For dynamic code, use the ordinary Groovy compiler, so Groovy++will not destroy your Groovy code.
Personally, I prefer the so-called mixed compilation mode. In this mode, the static compiler does its best to parse methods and properties, but if the parsing fails, it will generate dynamic calls. This approach combines Groovy's dynamic characteristics with fast computing to the greatest extent.
Why do we need a standard class library?
Our standard class library is an extension of Groovy. As for why the standard class library is needed, there are two reasons: first, Groovy implements its services in a dynamic dispatching way, which is not the case in Groovy++. The appearance of Groovy++standard class library does not mean that the performance of Groovy standard class library is poor, but because it lacks type information and is not suitable for use in static languages; Second, because Groovy++has better performance, it is also meaningful to provide additional tool classes, such as scheduling multiple tasks on multi-core machines or providing functional operations on collections.
Another thing I'm proud of is that this Groovy++standard class library is all written in Groovy++, and none of them is written in Java.
What are the current shortcomings of Groovy++?
I only found a small inconvenience - it is not necessary to simply change from dynamic code copy/paste to static code. (Because additional type information may be required).
How does Groovy++compare with Scala/Clojure?
Groovy++has drawn many useful ideas from them (such as actor and trait), but Groovy++is closer to 9 million Java developers. The learning curve is smoother for them.
Tell me about the project roadmap?
In the next two to three weeks, we want to release version 0.2, which will include a full functional static compiler. Then we will focus on solving bugs, writing routines, documents and manuals in a month or two. Make preparations for 0.5% in April and May. At the same time, we will also improve the standard class library to better support multithreading and distributed programming.
We have many ideas in this field - distributed actors and data cache, software transaction memory, erlang type supervisor tree. It is hard to say which of them will enter the standard class library, which may create separate projects, and which will affect other projects such as GPars. It is certain that Groovy++, which integrates expressiveness, performance and compile time checks, can become a candidate language for solving complex problems, and make these problems easier for ordinary developers to solve.
What are the plans for IDE support?
Any IDE that supports Groovy well can be used without any specific IDE support.
