Java isn’t just a language; it’s an ecosystem. You can write code for the JVM without writing any Java. This gives you the option of using a more modern language. Some of the shortcomings of Java are obvious. It makes you write a lot of boilerplate code. It supports functional programming only as an afterthought; the lambda feature is a kludge. The NullPointerException is every Java programmer’s bane.

In 2004, a group led by Martin Odersky released an updated version of the language, called Scala (“scalable language”). It added features such as objects for everything, functions as assignable data, type inference, and pattern matching. It compiles to Java bytecodes and can be mixed with Java code.

Another language aimed at the same goals is Kotlin, released by JetBrains in 2012. It built on people’s experience with Scala. A common complaint with Scala is slow compilation time, and Kotlin offers compile speeds comparable to Java. It’s recently gotten a big boost from Google, which has declared it a first-class language for Android development.

If some features of Java constantly annoy you, you’ll find things to like in both languages. If you’re annoyed enough to make the jump, which way should you go? Should you choose the maturity of Scala or the freshness of Kotlin? There are benefits to each.

Solving problems different ways

Kotlin and Scala, like Java, are statically typed. Whatever type a variable starts out as, it will keep it for its whole life. But both of them save you some of the effort of declaring every variable. You can implicitly declare a type with an initializer. In either language you can write

var count = 1

That makes count an integer. Notice that no semicolon is required. The difference between the languages is that Scala goes much further in allowing implicit conversions. If you use x.transmogrify(), and x belongs to a class which doesn’t have a transmogrify function, that isn’t necessarily an error. You can create an implicit class which has a transmogrify method, and the compiler will figure out, without making you do any casting, whether it can step in to do the job.

Kotlin’s creators found this a little too free-wheeling. It lets you define extension methods on a class, adding custom functionality. You can do this even on standard data types. (Remember, everything is an object, so every data type is a class. Boxing of simple data types is no longer needed.)

Null values are a huge headache in Java. Scala helps to relieve this in a couple of ways. First, variables must be initialized. You can initialize them to the default value (var a:Int = _), which is often null, but at least it makes you aware you’re doing it. Second, the Option class helps in guaranteeing null-safety in parameters and returned values. It’s one of the more complicated features of the language to understand, but it gives you a lot of control.

Kotlin gets right to the point. By default, it doesn’t allow variables to have the value null. You can declare a variable to be nullable if you really need to, by putting a question mark after the type. If you’ve worked with Swift, this approach will sound familiar. If you use nullable values, the compiler does extensive checking to make sure you aren’t putting them at risk of a NullPointerException and will give you a compile-time error if you are.

Java makes you use a regular class or an enum if you just want to package some data together in an object. Scala and Kotlin offer some better options. Scala gives you the case class, which a specialized class for data objects. It automatically defines accessor functions (why doesn’t Java just do that?). Instances are compared by structure rather than reference. A copy function is automatically provided to do a shallow copy.

Kotlin’s data class does pretty much the same thing. The main difference is that Scala has a powerful pattern matching feature which Kotlin didn’t pick up. A match statement is like a bionically enhanced case statement. Patterns can check not only literal values but types, lists, and ranges. Scala can do matching on all kinds of objects, but the feature is especially powerful with case classes.

Scala provides strong support for XML. You can put XML directly into Scala code and assign it to an XML object. This creates complications, since a <operator that isn’t followed by a space may be read as the start of an XML expression. Kotlin uses the more traditional approach of classes to handle XML objects.

Type classes are a feature of Scala that doesn’t have an equivalent in Kotlin. A type class defines a set of operations which member classes must support. This isn’t like subclassing in Java; a type class can be added to types that already exist. It lets the developer create new kinds of polymorphism with existing types. Extension functions in Kotlin aren’t the same thing, but they let you add common ground to different types, so they address some of the same needs.

The feel of the language

OK, there are differences between the languages, but they aim at more or less the same thing. You can learn either one. Are there bigger, more philosophical reasons for choosing one or the other?

To some people, the difference is that Scala is more aimed at exploring new ideas, and Kotlin is more focused on getting results. Kotlin’s emphasis on fast compilation and its removal of some of Scala’s more esoteric features reflect this. Scala just lets you do lots of things. The operator name ?:+ appears to be legal, and maybe there’s a reason you’d want to use it. Kotlin is more restrictive. Some would say saner.

If you love functional programming, Scala has more of its features than Kotlin. Type classes are a functional programming feature. As another example, Scala supports currying and partial application, which are ways to break down functions that take multiple arguments. This provides additional flexibility in using argument lists. Kotlin provides ways to do the same things, but they might not be as mathematically elegant.

People who have learned Scala thoroughly love it. It takes more effort, but it lets developers do things they can’t do in Kotlin. Kotlin adherents often find that much flexibility more confusing than useful.

Practical considerations

Sometimes the realities of what you’re trying to do are the main factor. You need to pick the language that will let you do the job, even if you don’t like it quite as much. If you ‘re going to do Android development, Kotlin is the only choice. Android doesn’t use Oracle’s JVM, so you can’t use any old JVM-compatible language. Kotlin has the tools for compiling, debugging, and running software on Android. It’s built into Android Studio, starting with version 3.0.

Outside Android, Kotlin’s options are more limited. Are you committed to Eclipse for your IDE? You can use it to work with both languages, up to a point. The Scala IDE for Eclipse is more mature than the Kotlin plugin, which is a bit painful to set up. Some users have reported trouble getting the latter to work. The situation for NetBeans is similar. With Kotlin’s growing popularity, the situation may be more equal in a year or two. If you like working from the command line, the IDE situation isn’t an issue, and Kotlin has all the necessary tools.

Kotlin is still maturing, but many Java people find adopting it is an easier transition than Scala is. The one that works best for your needs will depend on your personal style and your practical aims. Look at both carefully before making a decision.

If you enjoyed this article please share it! This is the biggest compliment you can give a writer! Thank you!