[pron]

There are many feature-level differences, but the biggest differences are in the approach, goals and philosophy[1].

When it comes to philosophy, Kotlin is a modern Java -- i.e. a "blue-collar" language[2], aiming to adopt only tried-and-true ideas and not to break new grounds. Scala is most certainly not blue-collar, serving as a basis for a few PhDs, and incorporates many ideas that haven't been tried in the industry. Scala is adventurous; Kotlin tries hard not to be.

When it comes to goals, Kotlin aims to solve Java's pain points (nulls, properties, beans) while keeping the same libraries. Kotlin doesn't even have much of a runtime library to speak of. A Java library is an idiomatic Kotlin library, and is almost indistinguishable from Kotlin libraries when used from Kotlin (i.e., no limited functionality, no wrappers needed). Kotlin's design is built around this core idea. While Scala interoperates with Java, it has its own runtime library, and many types (e.g. collections) need to be wrapped when passed across languages.

When it comes to approach, Kotlin is developed hand-in-hand with its tools (IDE, build, multi-lang compilation), and made to be gradually adopted into Java codebases. You can easily mix Kotlin and Java classes in the same package (the IDE will even convert any given Java class to a Kotlin class, and seamlessly handle mixed-language codebases). Scala and its tools are developed separately, and it's built to be independent of Java (although it interoperates with it). Another difference in approach (although it's still theoretical so not quite fair) is that the Koltin dev promise that the language will be source and binary backwards-compatible starting with the imminent version 1.0 (though this promise hasn't been put to the test), while Scala allows for occasional breaking changes.

[1]: Java and C have very similar syntax, yet the two are completely different (although Kotlin and Scala are probably more similar to one another than Java and C).

[2]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....

[runT1ME]

You keep spreading your misinformed FUD about scala every time someone mentions it in a thread. Do you really continue to maintain the position that scala is not used successfully by large teams?

[incepted]

Are you responding to the right post? Because the post above yours doesn't say anything about that.

[jinst8gmi]

Pron tends to zealously defend Java and Kotlin and bash pretty much anything else, especially Scala, but his post here today seems perfectly reasonable.

[pron]

The only thing that seems to be spreading is the use of the word FUD as well as personal attacks by some people who think they should be rude to those they disagree with. A few conditions have to be met in order for a statement to qualify as FUD: 1/ It has to be false or at least grossly inaccurate, 2/ its falsehood/inaccuracy has to be intentional, and 3/ it has to be negative. My statements fulfill none of those conditions, so relax. It's been a long time (well over a year, if not two, IIRC) since I discussed my bad experience with Scala or said anything negative about it, and for the record, I have never said that Scala is not used successfully by large teams, only that I have had a very bad experience adopting Scala in a large team, an experience shared by other such teams, and that I believe it may not be a good choice in such circumstances. My opinions are neither overly negative nor uncommon, the only difference is that I was foolish enough to sound them in spite of the rampant rudeness of some who for whatever reason took personal offense. I have also repeatedly said that I realize that that experience isn't universal.

Also, I would appreciate you stop saying that my opinions are misinformed (as they are most certainly not), unless you care to point out my errors. It's OK to disagree, and I don't think you should expect everyone to share the same opinions with you.

BTW, I think that much of the (valid) disagreement stems from a difference in perspective. Some people concentrate on language features, while I could care less whether a language has higher-flavored emojis or subliminal piping. I view those features as means to an end, so first and foremost I care about that end -- what the language aims to achieve -- long before getting to how it aims to achieve it, which, IMO, is only a concern once the goals match your own, otherwise the discussion is purely academic (which may be interesting in its own right, but not my focus).