Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language

In a previous post I pointed out that one of the more obvious recent changes in the Java landscape has been the meteoric rise in popularity of other languages for the JVM.  Some are old and some are new but JVM compatible versions of established languages with the likes of JRuby and Jython, Java-esque languages like Groovy and Scala and brand new languages like Clojure and Kotlin offer genuine options for those that appreciate the performance and reliability of the JVM but also want a different syntax.

In an ideal world all developers would be able to develop in the language of their choice. The reality is that as developers we are constrained by the suitability of the language, the tooling support and by what languages companies are actually using. Firstly, you choose the language appropriate to the domain – one that lets you do your job quickly and easily but with the appropriate level of support for your non-functional requirements like performance.  Secondly no one wants to be slogging through the coding process in a simple editor. Yes, I know that we could all use vim or emacs but being able to refactor large swathes of code easily and quickly (hello TDD!) kind of demands a modern IDE like IntelliJ or Eclipse. Thirdly, the reality of the situation is that very few of us are in the position to be able to dictate to our employers what language we should be using. Learning a language with rising popularity also means that you have a greater chance of being employed in the future (which is nice) but employers drive the acceptance of new languages.

The fact is that many companies boast about using the latest and greatest languages since it makes them more attractive to candidates. You can barely move for the blog posts and tweets of people raving about how their company has completely changed their development process with a new language but what is the real picture?

For a useful indication of industry acceptance we can go on the job trends on The grand daddy of language charts is Tiobe but it’s no use at this point since a) it does not provide sufficient information and b) is too easily gamed – yes Delphi dudes, we know what you did. Now before you complain, I know that using something like this is far from perfect and a long way from scientific but unless you fancy doing a longitudinal study going asking all the companies what they are using and believing their answers are real rather than marketing fluff, it’s probably good enough to be illustrative.

So what can this tell us about the how the industry sees the major language of the JVM: Java, Groovy, Scala, Clojure, Jython and JRuby*. What happens when we have a look at the percentage of all jobs that mention these languages

Umm, well… it’s pretty obvious that despite all the industry noises about other languages, Java is still massively dominant in the job marketplace with almost 3.5% of the jobs requiring Java knowledge. We all know that Java is an industry heavyweight but it is a bit of a surprise that in comparison the other languages are an indistinguishable line. Welded close to the 0 line, they would need some seriously exponential grow to start to threaten Java.

So what happens when you remove Java….

This is a lot more interesting. Firstly Jython was the first language other than Java that was really accepted on the JVM. Groovy started to pick up in 2007 and quickly became the first of the alternate languages, no doubt driven by Grails. Clojure and JRuby have never really garnered much support despite the recent rise in the last 18 months or so. I think the most interesting point is the recent increase in the acceptance of Scala. Currently third behind Jython, the gradient indicates that it will soon move into second. Comparing the grow rate of Scala and Groovy on a relative basis we see the following.

So we can see that Scala has finally crossed over Groovy’s growth rate. It’s completely reasonable to say that this could be temporary and that we should not read too much into this but there are a few data points there so it does not appear a flash in the pan.

So what can we say; while you’ll want to dust off the old Groovy text books and maybe have a look at some Scala tutorials, the best thing you can do is to keep your Java-fu in top notch order. As far as the industry is concerned Java is still the Daddy of the JVM languages and seems to being staying this way for some time.

* – I did originally include Kotlin and Gosu but since there were 0 jobs for Kotlin and only about 9 for Gosu they would only have been noise.

10 thoughts on “Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language

  1. Charles Oliver Nutter

    I think it would be more appropriate to compare “Ruby” and “Python” instead of “JRuby” and “Jython”. There are a number of Ruby users that do not advertise the fact that `they’re using JRuby, and we JRuby folks work very hard to make JRuby work just like Ruby. If you do an Indeed graph with Ruby, the others (Scala, Groovy, Clojure) barely raise their heads above the line, and a Ruby job is potentially a JRuby job.

    1. Martin Post author

      That’s a fair point Charles. Initially, I did look at Ruby and Python but there were two issues as I saw it. Firstly, both these languages have been out a reasonably long time so would hide the usage of the JVM versions. Secondly, I have to disagree with the idea that ‘a Ruby job is potentially a JRuby job’ since my experience is that the vast majority of companies use the native version and would not consider JRuby or Jython. But of course, YMMV.

      1. Charles Oliver Nutter

        At the very least, not searching for “Ruby” unfairly penalizes JRuby. JRuby is not a language, it’s an implementation of a language. The others are all languages on their own. It would be like comparing “OpenJDK” or “JRockit” or “J9” postings instead of just “Java” postings.

  2. Sean O'Halpin

    Thanks to Charles and the rest of the contributors to JRuby (who are a pretty talented bunch BTW), JRuby is phenomenally compatible with MRI Ruby 1.8.7 and 1.9.2. I suspect we Rubyists tend to consider it just another tool in the box to be used when you need access to the wealth of great Java libraries, native threads or excellent performance for long-lasting processes. We just don’t have a JVM-centric view of it. There are plenty of other languages built with the C library, but I don’t use them. I guess MMDV 🙂

  3. Paul Phillips

    After analyzing current trends, I confidently predict that rising meteors will remain uncommon for some time yet.

  4. Pingback: How to choose programming language for given task? | Software Engineering

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.