Hacker News Reader

Comment by aliakhtar | Hacker News Reader

It pisses me off a bit to not see Scala mentioned anywhere. Scala has everything Kotlin has, and a lot more.

Which could be considered a reason to use Kotlin instead. Scala is a more powerful footgun. You pay for the power in overengineered code, slow compile times, and worse compatibility with other JVM languages.

> overengineered code

False, scala is really concise.

> slow compile times

A few seconds slower on average, you mean

> worse compatibility with other JVM languages.

Its completely backwards compatible with Java.

I've inherited a large scale codebase and it's been interesting to put it mildly. I agree with GP that Scala's power lends itself to building unnecessarily complex systems.

- Scala has a lot of cool, but sometimes confusing features. Implicits, companion classes, apply/unapply.

- our compile times are 5-10 minutes in CI. I'm sure we can make it go faster, but it requires digging into a 500 line SBT file.

- Scala seems to encourage building tangled webs of actors with Akka. I understand the benefits of actors. I think the benefits are overstated vs threads when you need less than 10k threads or so.

All of what you're describing here is bad programming practices. Bad programming practices * scala's power = Incredibly bad work.

If you're a good programmer who writes well engineered code, you can do that incredibly well in Scala. Good practices * Scala's power = Great productivity + really good work.

Companions are in Kotlin too. Apply and unapply - I never saw this being a problem even for some new programmers switching from Python.

Implicits are kinda harder to use, but this is an advanced feature meant for library writers, not application programmers. Despite their power I find them much nicer to use than c++ templates. And there is nothing comparable in Kotlin, and insufficient abstraction can sometimes lead to actually more complex code than in Scala.

Scala compatibility with JVM is the same as Kotlin's. It is implemented the same way in both languages - they compile to JVM bytecode and as long as you keep away from non-Java features, interoperability is good both ways. If you start using stuff not directly supported by Java like default arguments or multiple inheritance of traits, then calling Scala/Kotlin code from Java is similarly bad experience. Scala has also a few more non-Java features e.g. macros or implicits, so I get how you could end up with this impression. Just don't use these features of you need to call your code from Java.

As for compile times, Scala with Bloop is the fastest of JVM languages I ever saw. We switched to compile Java with Bloop because it is orders of magnitude faster than Maven/Gradle. Bloop works for Java and Scala, but not Kotlin. So Kotlin, having really nothing comparable at the moment, is currently the slowest to compile from these three languages.

Something doesn't add up. First you say (emphasis mine):

> Scala compatibility with JVM is the SAME as Kotlin's.

Then you follow up with:

> Scala has also a few more non-Java features

These are contradictory claims. OP had a very good point about Scala being a more powerful footgun. Unfortunately, consciously avoiding features is not a matter of "just", and rarely works out in practicality.

No they aren't contradictory. What is the compatibility of a feature that even doesn't exist in Kotlin? How can be the lack of way to call a Scala macro from Java a disadvantage, when Kotlin doesn't allow you to call a macro from neither Java nor Kotlin, because this feature doesn't exist? Scala is strictly superior in this case.

And you need to avoid some features only in code that gets called from Java, not the whole codebase. Calling it this direction is very rare and not really a problem. Most codebases call Java from Scala and this is easy and fully supported.

100 intercompatiblity is a feature.

But Kotlin doesn't have 100% interoperability! There are features in Kotlin which don't map nicely to Java features. For example you can't call methods with default arguments from Java without resorting to unreadable hacks relying on a way defaults are implemented (same is true for Scala).

The Kotlin creators were looking to create a modern language without some of the issues that Scala has. Judging from its rapid growth in popularity, it is doing a few things right.

I think its growing because its the only way to do Android dev if you don't want to do Java 6. For that, its still great, but for any backend programming, you should consider getting the real thing (Scala) and not its watered down copy.

Watered down is a feature.

Code bases with Scala tends to be unreadable for people not well versed in the language. Kotlin is mostly just a better Java. So it's easier to introduce. And the interop is first class, so it's really easy to mix and match java and kotlin, which also makes it easier to gradually introduce.

My experience tells me the opposite. Scala codebases written by professionals are very readable even to people not knowing Java, but Python. Many analysts use Scala and Python. The only people I met who complained on Scala complexity were guys who were either invested heavily in another language (eg Haskell), in which case it was just a subjective opinion or people who struggled with writing good Java code as well.

> unreadable for people not well versed in the language

This is a sign the language is pulling its weight. We're going to spend most of our careers at the top of the learning curve, so we shouldn't optimize for briefly being at the bottom.

Not only that, Google and JetBrains cleverly sell Android Java as Java when talking about Kotlin capabilities over Java.

If Android Java was actually modern Java, the sales pitch wouldn't be as strong.

I think Kotlin is outgrowing Scala on the backend as well. Spring is basically not bothering at all with Scala but they are adding lots of Kotlin specific functionality in the last two years. Check this recent presentation of the state of Kotlin in Spring: https://www.infoq.com/presentations/spring-kotlin-boot-kofu/

If you read between the lines, what they are saying is that Kotlin is now the primary language to use Spring with.

I am not a user of either, but my understanding is that Kotlin is a lot easier to use with existing Java projects.

Absolutely untrue, Scala is completely backwards compatible with Java - you can use all your java code in Scala and even write scala as mostly a better Java.

Sadly it is actually the case. I recently worked on a project using the AWS SDK. We had written our code using Scala and had to up version the AWS SDK to 2.0. Because we used reflection with it, we encountered a Scala compiler bug (an illegal cyclic reference) and had to rewrite it all in Java.

Reply on news.ycombinator.com