Re:Kotlin Features I miss most in Java
by lmm on Monday October 30, 2017 @08:08AM
(#15584394)
The reputation is undeserved as a description of the language proper; it's a flexible and powerful language that allows libraries to do quite a lot, so people often mistake library features for language features. In a way it ends up being a bit like lisp: a toolkit for allowing you to construct your own (hopefully domain-appropriate) language rather than a language as such. Like how people will sometimes criticise Ruby for things that turn out to be a Rails feature rather than part of the language itself.
It is fair to say that many Scala codebases are complex and difficult to work on. It's a language that punishes poor choice of libraries much harder than many languages (particularly if people are used to JVM languages - what libraries/frameworks can do in Scala is much closer to what they can do in Python/Ruby/...). I don't think it's "fair" to compare Scala to Kotlin on those grounds, simply because we haven't had time for generations of Kotlin frameworks to build up. But obviously that kind of fairness is not your concern if you're a business making a choice of tools.
If you're choosing a language for a short-lived codebase then Kotlin might be a good choice if it does what you want. What I would say is, if you're trying to choose a language for a codebase that will live for 5-10 years, try to think about what Kotlin is going to look like in 5-10 years. Right now Kotlin is able to be a lot cleaner than Scala (at least on a superficial level) because it doesn't have backwards compatibility with large existing codebases hanging over it. That isn't always going to be the case.
It is fair to say that many Scala codebases are complex and difficult to work on. It's a language that punishes poor choice of libraries much harder than many languages (particularly if people are used to JVM languages - what libraries/frameworks can do in Scala is much closer to what they can do in Python/Ruby/...). I don't think it's "fair" to compare Scala to Kotlin on those grounds, simply because we haven't had time for generations of Kotlin frameworks to build up. But obviously that kind of fairness is not your concern if you're a business making a choice of tools.
If you're choosing a language for a short-lived codebase then Kotlin might be a good choice if it does what you want. What I would say is, if you're trying to choose a language for a codebase that will live for 5-10 years, try to think about what Kotlin is going to look like in 5-10 years. Right now Kotlin is able to be a lot cleaner than Scala (at least on a superficial level) because it doesn't have backwards compatibility with large existing codebases hanging over it. That isn't always going to be the case.