4 ms·

Looking at the syntax briefly it seems very similar to Scala. Is there any major differences between Scala and Kotlin?

by davidcaseria 11y ago

baq 11y ago
i'll wager a guess: kotlin compiles faster.
- eropple 11y ago
  Much faster. So very much faster. I won't trade off so many features for compile speed as to make Go seem like a good idea, but Kotlin is hitting a really nice balance for me between Java and Scala on the feature/iteration-loop front.
axelfontaine 11y ago
https://kotlinlang.org/docs/reference/comparison-to-scala.html https://kotlinlang.org/docs/reference/comparison-to-scala.ht...
alfongj 11y ago
I'd say the syntax is halfway in between Java and Scala. That makes it much more approachable for Java developers (you can learn the basics in an afternoon), but also less flexible than Scala sometimes.
- jinst8gmi 11y ago
  Yeah, Kotlin looks largely like a simpler, stripped down version of Scala. It's a lot closer to Scala than it is to Java, but it's close enough to Java devs to not have to put in much effort to learn vs learning Scala. I prefer Scala, but not everyone wants to invest the time to learn it in order to gain maybe 25% more expressiveness. Kotlin also seems like a better fit for Android than Scala (and Java for that matter).
  - justthistime_ 11y ago
    In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).
    - jinst8gmi 11y ago
      Not everything in Scala can be cleanly translated into Java, but Kotlin looks more like a subset of Scala than it does a superset of Java. The syntax is very close.
gecko 11y ago
Kotlin has a much simpler syntax, and much simpler semantics, than Scala. Specifically, it's largely a very, very good syntax, and small class library extension, for otherwise-vanilla alternative syntax to Java. This is the whole reason for its existence: Kotlin code cleanly interoperates, in both directions, with existing Java code. From my own experience, this means that it's very easy compared to Scala to introduce into an existing code base: you can sanely go class by class, file by file, cleaning up code, relying on the existing unit tests, without breaking anyone's workflow. As a result, it has, in my experience, proved a lot cheaper than Scala to train new devs in it as well. That's not to say that it's all just syntax, though. Kotlin also brings null safety, traits, builders, and some other key things over from the Scala, Groovy, other sources, which has proven to be a major productivity boost. Its collections library is a lot saner (IMHO) than Java 8's due to better generics support. It adds data types and value semantics for when you need them as well. But it does so in a way that (again, based on experience introducing Kotlin into a company after Scala had failed to gain any traction) is a lot easier to teach to most developers, and a lot easier to integrate into existing workflows.
- mike_hearn 11y ago
  Just to clarify, Kotlin doesn't have a collections library. What it does have is some clever compiler magic over JDK collections that adds: • Mutable vs immutable views (List is read only, MutableList is read/write) • Safer generics: map[key] which is translated to map.get() has the type bound you would expect rather than Java's much weaker Object type. • Lots and lots of extension functions to do things like functional programming with them However, behind the scenes they are still JDK collections, so you can call to and from existing Java with no problems and ... you know, actually, JDK collections library is pretty good. Especially once you get into the scalable concurrent collections.
  - gecko 11y ago
    Eh, I get why my phrasing might make it sound like they had a totally separate collections hierarchy; you're right, they don't. But I'd count the changes you list--especially the extension methods, which basically provide an entire Java 8-streams-like API that runs comfortably on top of even Android's superannuated Java--as a collections library in its own right. (Hell, even the fixes they do at the compiler level to maps makes the entire collections API feel a lot more like .NET, with its reified generics, and a lot less like Java's weird situation.)
whateveracct 11y ago
Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.
- pron 11y ago
  https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a
- hrjet 11y ago
  I agree. One thing that is sorely missing, for example, is a way to define recursive values. In Scala, to express a recursive parser combinator: val e = p | e You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.
  - chrisseaton 11y ago
    Wow can you really write val e = p | e in Scala? How does that work with eager evaluation?
    - hrjet 11y ago
      It's not eager. The | combinator takes lazy parameters (called pass-by-name in scala). So it essentially gets translated to: val e = operator_pipe(() => p, () => e) Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.
- edgyswingset 11y ago
  (disclaimer: I think Kotlin is cool) And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.
  - icholy 11y ago
    It's not that hard to implement your own stream abstraction.
deleted 11y ago
[deleted]
pron 11y ago
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.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....
- runT1ME 11y ago
  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 11y ago
    Are you responding to the right post? Because the post above yours doesn't say anything about that.

Looking at the syntax briefly it seems very similar to Scala. Is there any major differences between Scala and Kotlin?

baq 11y ago

i'll wager a guess: kotlin compiles faster.

eropple 11y ago
Much faster. So very much faster. I won't trade off so many features for compile speed as to make Go seem like a good idea, but Kotlin is hitting a really nice balance for me between Java and Scala on the feature/iteration-loop front.

axelfontaine 11y ago

https://kotlinlang.org/docs/reference/comparison-to-scala.html https://kotlinlang.org/docs/reference/comparison-to-scala.ht...

alfongj 11y ago

I'd say the syntax is halfway in between Java and Scala. That makes it much more approachable for Java developers (you can learn the basics in an afternoon), but also less flexible than Scala sometimes.

jinst8gmi 11y ago
Yeah, Kotlin looks largely like a simpler, stripped down version of Scala. It's a lot closer to Scala than it is to Java, but it's close enough to Java devs to not have to put in much effort to learn vs learning Scala. I prefer Scala, but not everyone wants to invest the time to learn it in order to gain maybe 25% more expressiveness. Kotlin also seems like a better fit for Android than Scala (and Java for that matter).
- justthistime_ 11y ago
  In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).
  - jinst8gmi 11y ago
    Not everything in Scala can be cleanly translated into Java, but Kotlin looks more like a subset of Scala than it does a superset of Java. The syntax is very close.

gecko 11y ago

Kotlin has a much simpler syntax, and much simpler semantics, than Scala. Specifically, it's largely a very, very good syntax, and small class library extension, for otherwise-vanilla alternative syntax to Java. This is the whole reason for its existence: Kotlin code cleanly interoperates, in both directions, with existing Java code. From my own experience, this means that it's very easy compared to Scala to introduce into an existing code base: you can sanely go class by class, file by file, cleaning up code, relying on the existing unit tests, without breaking anyone's workflow. As a result, it has, in my experience, proved a lot cheaper than Scala to train new devs in it as well. That's not to say that it's all just syntax, though. Kotlin also brings null safety, traits, builders, and some other key things over from the Scala, Groovy, other sources, which has proven to be a major productivity boost. Its collections library is a lot saner (IMHO) than Java 8's due to better generics support. It adds data types and value semantics for when you need them as well. But it does so in a way that (again, based on experience introducing Kotlin into a company after Scala had failed to gain any traction) is a lot easier to teach to most developers, and a lot easier to integrate into existing workflows.

mike_hearn 11y ago
Just to clarify, Kotlin doesn't have a collections library. What it does have is some clever compiler magic over JDK collections that adds: • Mutable vs immutable views (List is read only, MutableList is read/write) • Safer generics: map[key] which is translated to map.get() has the type bound you would expect rather than Java's much weaker Object type. • Lots and lots of extension functions to do things like functional programming with them However, behind the scenes they are still JDK collections, so you can call to and from existing Java with no problems and ... you know, actually, JDK collections library is pretty good. Especially once you get into the scalable concurrent collections.
- gecko 11y ago
  Eh, I get why my phrasing might make it sound like they had a totally separate collections hierarchy; you're right, they don't. But I'd count the changes you list--especially the extension methods, which basically provide an entire Java 8-streams-like API that runs comfortably on top of even Android's superannuated Java--as a collections library in its own right. (Hell, even the fixes they do at the compiler level to maps makes the entire collections API feel a lot more like .NET, with its reified generics, and a lot less like Java's weird situation.)

whateveracct 11y ago

Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.

pron 11y ago
https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a
hrjet 11y ago
I agree. One thing that is sorely missing, for example, is a way to define recursive values. In Scala, to express a recursive parser combinator: val e = p | e You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.
- chrisseaton 11y ago
  Wow can you really write val e = p | e in Scala? How does that work with eager evaluation?
  - hrjet 11y ago
    It's not eager. The | combinator takes lazy parameters (called pass-by-name in scala). So it essentially gets translated to: val e = operator_pipe(() => p, () => e) Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.
edgyswingset 11y ago
(disclaimer: I think Kotlin is cool) And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.
- icholy 11y ago
  It's not that hard to implement your own stream abstraction.

deleted 11y ago

[deleted]

pron 11y ago

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.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....

runT1ME 11y ago
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 11y ago
  Are you responding to the right post? Because the post above yours doesn't say anything about that.