Gradle announced this week its plans to incorporate the Kotlin programming language into the build system, and have this be the favored approach for writing build scripts and plugins. It shouldn’t be to anyone’s surprise that this ruffled some feathers in the Groovy ecosystem.

To start with, let me make one thing clear: I don’t share any of the concerns that have been raised about the future of Groovy, given Gradle’s decision. I think Cédric’s statement, "for those who worry, no, we’re not dropping [Groovy] support," is really all that needs to be said, but still the concerns persist.

In technology, we have short memories…​ It was not so long ago that fears overwhelmed our community when Pivotal announced it would no longer be sponsoring Groovy and Grails. In spite of that announcement, both the language and the framework persist thrive. Groovy has a long history, and throughout that history there have been many occassions that have brought forth concerns of certain doom for the language. In all these cases, Groovy has carried foreward, continuing to gain in popularity with ever-growing adoption.

This circumstance is no different. Groovy has not been dealt a lethal blow by Gradle’s choice to introduce Kotlin, and it would be near-sighted to think so. For one thing, as Cédric explained, Groovy will not stop being supported in Gradle. For the purposes of backward compatibility, there’s no future for a Groovy-free Gradle. Furthermore, the plethora of mindshare and knowledge base that supports Gradle’s integration with Groovy is not something that can or should be replaced overnight.

And the team at Gradle knows all of this, and they are making it clear that they will continue to support Groovy going forward. So, everyone, just calm down…​ Let’s take a step back…​

Many of us (myself included), like and use Gradle because it is the fastest, easiest-to-use, most extensible, and most powerful build tool for the JVM. The recent advancements in performance, incremental builds, and continuous build mode make it the premiere choice for building all types of software, but especially those that target the JVM. Notice that none of these reasons are the fact that it uses Groovy.

To be perfectly honest, I could care less what programming language underpins the domain (very) specific language that Gradle uses to describe builds. I’ve worked on projects with high levels of build complexity and never once did I think, "gee whiz this is so great because it’s Groovy". Or, alternatively, "ohmagosh this would be so much easier if it were {Java[7|8],Scala,Ceylon,Kotlin,etc}".

What I like about Gradle is how they have made it so that builds can be defined in a semantically expressive way that is concise and clear. And for a long time, Groovy serviced them well as the language upon which that DSL was able to be built. Since then, languages like Kotlin have come around that allow for similarly concise DSLs to be built, but also inherently provide static typing.

Now, I’m going to pause here for a second and address the obvious immediate thought here — Groovy is able to be statically compiled. This is true, and there is even work being done to allow statically compiled build scripts in Gradle, and I think that is fantastic. Again, I want to point out the fact that Gradle has explicitly said they have no plans to not support Groovy — they’re simply adding the capability to use Kotlin as well.

They are saying slightly more than that…​ They are favoring Kotlin over Groovy as the language for building plugins going forward. But, they’re doing this for good reasons; performance being one of them.

Performance is of paramount importance to Gradle. It is the seemingly undying motivation for everything they are doing these days. And, honestly, it has to be…​ Gradle powers massive development shops (like Netflix and LinkedIn), who run dozens, hundreds, or even thousands of builds a day. And those builds are not always simple. In recent years, Groovy has also focused on performance, to the point that today it is very fast, and with a few tricks can be as fast as native Java. In its default form, however, Groovy is a dynamic language with a dynamic dispatching system that is enacted (and affected) at runtime. This feature is what gives Groovy so much power and flexibility, but it also makes it slower than a statically compiled language like Kotlin.

It is because of Gradle’s emphasis on performance that Kotlin is favored, not because of some massive ineptitude of Groovy’s. No, in fact, quite the opposite — Groovy is, and will continue to be, a remarkably powerful language in the build system’s toolbelt. There will be builds that will inherently require the dynamic capabilities that Groovy has, and for them Gradle will have first-class, silver-platter support.

This is not a case of either-or; this is a case of choosing the right tool for the job.

Beyond even all of this, what Kotlin gives us that Gradle’s Groovy support doesn’t is out-of-the-box support with the two most popular IDEs (Eclipse and IntelliJ IDEA). Putting aside the fact that Kotlin was invented by JetBrains, its static nature inherently lends itself to predicability by the IDE. Any Java develoepr who has tried to work with a Gradle build script in an IDE knows that you basically get no help. IntelliJ has done some great work over the years trying to predict what’s going on in a Gradle build script, but even today it’s nearly impossible to rely on IDE support when crafting or modifying your build. This has made the act of wrangling a build script something of an art — a trade skill reserved for a "build master" — and not something easily consumable for Java-fluent-but-new-to-Gradle developers.

In my opinion, I think that Gradle teaming up with Kotlin is an excellent choice, because it will continue to advance the build system and make it better for everyone in the long run. The easier that it is to make build scripts, the more adoption and innovation we will see. Furthermore, having the IDE help means a great deal in terms of reducing complexity and finding bugs before runtime. For Gradle to continue on its trajectory of massive success, it needs this in its life. It is a very savvy move, and for that I applaud the team.

Through Gradle’s success with Kotlin, we will undoubtedly continue to see innovation and growth in Groovy. We will see its support in Gradle continue to assist in driving its vision, all the while refining its capabilities as a high performance, statically typed and compiled language. This is great for every facet of the GR8 ecosystem.

Gradle’s not abandoning Groovy, and Groovy’s not going anywhere. Sorry to everyone who thinks that this is a bullet-to-the-head for Groovy, but in time, I think you’ll find that Gradle’s choices today will continue to support Groovy in the long term.