Comment by pron | Hacker News Reader

Comment by pron | Hacker News Reader

To me it seems that while the two languages share some superficial similarities, they couldn't be more different from one another, to the point of being incomparable.

Kotlin is a language that is designed very much in accordance with the "Java philosophy"[1], which states:

Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.

Scala has a diametrically opposed design philosophy. It is very much PhD thesis material (multiple PhD theses), was built to study and experiment with novel ideas in language design, which are very unfamiliar, and happy to adopt things that are untried because they sound like a good idea and may be worth a try; it is decidedly adventurous, as opposed to the mostly conservative Kotlin.

So the choice between the two should be first and foremost be about which of these very different philosophies is the right one for your project and team. Comparing them feature by feature (even if a feature is a generally broad one, like "how easy it is to learn", is ultimately misleading) is misleading. Comparing a car and a tank feature by feature may give the impression that there is a wide overlap between them, and that they may be largely interchangeable, while, in fact, they are very different beasts, and rarely interchangeable.

[1]: http://dl.acm.org/citation.cfm?id=620728

Exactly. I've been researching Kotlin as a Java replacement at my company and would like to promote it as an all-around, traditional language. In my experience Scala is favored by language nerds (not derogatory!) and their code, while fabulously concise and clever, was largely unreadable outside of their clique and used paradigms that are bizarre to even seasoned developers.

Take a look at The Guardian newspaper's github repository for some professional Scala. It ain't pretty - implicits all over the place, liberally mixed with Cats and Scalaz. This is Scala's big problem - taken in isolation Scala-isms are comprehensible but it's the way the cleverness composes that leads to a big ball of mud. Add to that the tendency of Scala connoisseurs to throw-in Cats and Scalaz at every turn and you have a recipe for disaster.

I'm a Scala fan, so know that up front, but I don't think Scala is unreadable outside of language fanatics, but the language itself is definitely more complicated than Java/Kotlin/Go etc.

We've had a lot of success bringing people unfamiliar with the language (even with heavy usage of Scalaz) because we try to maintain the right ratio of "Scala experts" to "new to Scala". We end up with 1 to 7 more or less, and it seems to work well.

As long as there's enough resources to steer people away from writing ugly code, the payoff can be quite nice. I have never seen a null pointer exception, almost all of the issues we see in staging/dev are related to JSON/REST,and the only issues we've seen in production have been performance/latency related. Scala really allows us to narrow down the type of bugs we get.

The problem with Scala is that it is so expressive and powerful that it is really easy to write unreadable code, especially when delving into the heavy functional side. Scala is the C++ of the JVM.

There will be programmers that want to use every feature all the time, and while this happens with every language, the most featureful ones suffer the most from this.

Yes, the problem with lack of clarity is more often than not the fault of the API designer, not the language. Non-traditional method names like ~%>$ or whatever should be done in a very clear and easy to understand way; if not, that's a feature of the language that was used poorly by the software engineer.

Scala actually has a very consistent and simple syntax which after some initial learning phase is very easy to follow.

The standard library on the other hand, like many APIs which are written in idiomatic Scala, can be difficult to understand, especially at first. I don't admit to understanding it anywhere near as well as I do the Java standard library.

But the issues with Scala in this area is more akin to finding issues with the Java standard library (there are tons!), rather than Java as a language or a VM (two other things which are also correctly referred to as 'Java')

One of the biggest humps I had when getting into Scala full time was getting my head around the fact that many of the features of Scala actually occur at compile time, which as a Java veteran was something that took getting used to.

> Yes, the problem with lack of clarity is more often than not the fault of the API designer, not the language.

Well, a language that enables unreadable cleverness can be said to be at fault. This is why languages, like Kotlin, that follow the Java philosophy, intentionally try to avoid introducing primitive constructs (regardless of whether you believe they are "intrinsically" "simple") that give rise to such cleverness, even at the cost of what others may call expressiveness. Valuing expressiveness over readability (which I here define to be no-cleverness) or vice versa is ultimately a matter of personal preference, but it is a value judgment that's made by the language, and languages that differ in the priorities of their values are very different from one another. Just as the difference between a pure language that guarantees (for the most part) immutability vs. a language that doesn't (even though no one is stopping library designers from writing only pure functions) is big, so is the difference between a language that guarantees (for the most part) readability vs. one that doesn't.

Reply on news.ycombinator.com