Sunday 22 May 2016

About Gradle, Kotlin and Inner Fear.

When the Gradle team made the recent announcement for Kotlin support in Gradle, it set off quite a bit of emotional reaction in Groovy-land. Waiting for the emotions to die down before writing something, Dan Woods beat me to it with a great & balanced response. He already said more than I would have written on the technical side and there is no need repeating it. It is worthwhile reading his response first.

I sense an inner fear in the Apache Groovy community. I have sensed it for a while (long before this announcement). People don't really want to talk too much about it in public media, but the conversations are happening. They are happening at conferences and they are happening in the pub.  People who are seen in public as big stalwarts of the language, are involved in these conversations. There is a fear that Groovy as a language is dying. There is a (misconstrued) fear that Groovy is slow. There is an inner fear that all of the wonderful open-source projects written in Groovy will fall by the wayside. To a great extent this fear is also driven by lack of work - how job ads are out there actively asking for Groovy work. These job ads are also driven by perception of the recruitment industry. Yet there are jobs, definitely not as many as Java, but a lot of these jobs are through personal referral - insider information if you must. All of the jobs I have seen and heard of, all tend to be mostly with innovative, smaller companies.

Groovy-based work tends to be Grails. This framework remains the flagship in the Groovy ecosystem, pushing the limits with what can be done with static typing in Groovy, yet balancing it with the flexibility of dynamic typing. I hardly hear of any complaints regarding performance in deployed Grails apps. (I am sure there are, but I just don't get to hear about them). More work also seems to be coming from Ratpack, and I can tell you using the Ratpack Groovy wrapper is just far more satisfying that using plain Java.

The place for me where Groovy is really excelling in is testing. There are a number of frameworks out there that is based on Groovy or have excellent Groovy wrappers. Spock Framework of course will always be the first mentioned.  This for me remains the best unit-testing framework on the JVM, irrespective of the development lanaguage of the production code. There are a bunch others such as
Geb (for Web UIs) and AccuREST (consumer-driven APIs). Have a look at this set of slides for an idea of how great Groovy-based frameworks are for testing.

Gradle is a next generation build tool. It is exploring next ways of building stuff, of expressing how build-and-deploy pipeline should work. In this evolution we are learning about what we as an industry want from future build tools. If it thus evolves over time that Kotlin shows that it is more than capable of helping shape the future of build tools, then so be it - we have tried and we have learnt.

There is a very good reason why Gradle started with Groovy - expressive & readable DSLs. With all the promise that Kotlin has as an upcoming language,  and as a user of Kotlin too,  it will need some ground-breaking changes to the language to beat Groovy in this respect.Kotlin is far better than Java in both expressiveness and readability, but it still does not match Groovy. (Kotlin has some features that are better than Groovy, but I am leaving that out for now as I am arguing Groovy's case).

The problem remains that Java programmers are a-dime-a-dozen (just like C# ones). It can make it hard to find the right, good technical people - a bit like looking for that needle in the haystack. When looking for polyglot people can be a challenge, as there are less of them. However, the chances are that they are the better ones. They are usually the ones that are willing to explore new ground, willing to think about the problem and willing to apply the correct language to solve the problem. There is too much Java (or C#) is the hammer and everything is a nail attitude with many people who have developer in their job titles. I would rather recruit (or work with) someone who is polyglot.

For me both Kotlin & Groovy are great languages for first-timers on the JVM. I know some people don't agree with me on this, but I think you can get quite a way on the JVM without knowing Java. I would rather start people off on either of these two languages than drown them in the very verbose syntax that is Java.

I can understand that there are inner fears in the Apache Groovy community and I can sympathise with that, but I think for it to grow, we need to keep on creating great DSLs around other libraries or write great DSLs with pure Groovy libraries to keep it alive. Beyond that these wrappers, libraries and frameworks need to be kept evangelised at non-Groovy conferences, otherwise they will remain little niche projects.

I want to applaud Dan Woods for addressing some of these community fears in public, I am looking forward to building more apps in Groovy and I am looking forward to using more Kotlin both inside and outisde of Gradle. I am also looking to talk more openly about these fears people have in public.

Edit: After I published this, Cedric Champeau  a Groovy committer, Gradle Inc employee and someone I have a lot of time for,  published his view on the matter. It's worth a read too.

No comments:

Post a Comment