8 ms·

Kotlin vs. Scala

94 points by dserban 9y ago

rb808 9y ago
> good fit for any projects where you want to combine these two programming styles. I'm always a bit wary of this. Its difficult to write a big code base in two different styles, I prefer a language that is mainly in one style. am I wrong?
- nine_k 9y ago
  Sometimes you don't write a project all by yourself, and have critical parts of it already written by completely different people years ago. In a situation like that, the ability to combine two styles with a relatively low impedance mismatch is very valuable.
- Sophistifunk 9y ago
  I find objects are excellent for... well, objects. Things with private state and behaviour. Services, GUI components, and the like. Functions and records are excellent for business data and the transformations of business data. ¿Por que no los dos?
- stickfigure 9y ago
  Write an immutable object with methods that return a new (changed) immutable object. Boom, you're an Object-Oriented Functional Programmer.
- jackmott 9y ago
  I sure don't want immutable linked lists everywhere
- naasking 9y ago
  > Its difficult to write a big code base in two different styles, I prefer a language that is mainly in one style. Not all problems are amenable to a single paradigm. Functional idioms are well suited to composing small systems, object-like abstraction is well suited to composing large systems and services. Note, object-like, not necessarily object-oriented in the Java sense.
kmizu 9y ago
It is very fair comparison than other "Kotlin vs. Scala" articles.
anorwell 9y ago
I've never used kotlin, but after reading the article, I wondered how it could be possible for kotlin to be null-safe and interoperable with Java at the same time. Turns out it's not [1]. Kotlin's null vs non-null types seem to be semantically the same as option vs non-option (as in scala). However, Scala allows any variable to be null separately from the type system, whereas Kotlin does not. It's not clear to me that Kotlin's approach is preferable here. Kotlin code that interfaces with Java gives the illusion of null-safety, but won't actually provide it. Scala does not attempt to provide this guarantee, which I don't think any language that interoperates with java can ever provide. [1] https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html
- bluejekyll 9y ago
  This might be a better link based on your concern: https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types https://kotlinlang.org/docs/reference/java-interop.html#null... This feels like a trad-off between ease-of-use/adoption. It's effectively undefined behavior to reference a nullable type from Java. Another way to consider this is that it's not necessarily worse than working natively in Java, but it can over time be better. This trade-off seems reasonable, as there is no great answer to this problem, but it's almost identical to Java's auto-unboxing of Integer types to int.
- vbezhenar 9y ago
  You can annotate Java code with @Nullable annotations. Kotlin will understand it and interop will be safe. Spring does it for example, AFAIK Guava does it as well. It won't work with Scala. Another advantage over Scala is that Kotlin compiler puts null checks on boundaries between Java and Scala, so even if your code pretending to be safe breaks in runtime, you'll catch error as soon as possible, this null won't leak into your internals to bite you tomorrow. But that's certainly a thing that could be improved. Majority of Java parameters/return values nullability could be automatically inferred by analyzing bytecode.
  - dep_b 9y ago
    Interesting. A bit worse than Swift and Objective-C. Objective-C has to promise `nonnull` otherwise it's shown as `ObjectType!` which basically means we treat it as non-null but it could be null and can be checked for null. Methods marked `nonnull` can still be nil sometimes, it's just a promise. Hard bugs to fix. Found one in an Apple framework where I could not think of anything else than comparing the address with 0x00000000 to see if it was nil.
pron 9y ago
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 http://dl.acm.org/citation.cfm?id=620728
- jonathanapp 9y ago
  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.
  - cutler 9y ago
    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.
jgrant27 9y ago
The article seems to paint Kotlin as not really much of a functional language as Scala is but more of a Java replacement. This is just not true. Both languages will not stop you from writing imperative code just as much as either can be used for a very functional style of programming. It really comes down to the caliber of developer and not the language choice here.
- foolfoolz 9y ago
  seems very elitist to say functional vs imperative depends on the caliber of the developer. there's plenty of reasons to choose either paradigm. language choice is a reasonable factor. just because you like OO doesn't mean you are bad and just because you like functional doesn't mean you are good
  - jackmott 9y ago
    what if my object has first class functions as all of its members? i am then bad and good?
    - foolfoolz 9y ago
      you're a few thousand unit tests away from web scale
  - jswizzy 9y ago
    I think OO when done right looks very much like FP. The problem is that OOP is just as hard as FP to write since most languages that claim to be OO languages are actually heavily procedural in nature.
guelo 9y ago
I thought the article was very light on details and lacking some important bits. This one is I think a better comparison at the language level: https://agilewombat.com/2016/02/01/scala-vs-kotlin/ https://agilewombat.com/2016/02/01/scala-vs-kotlin/
souenzzo 9y ago
What is the difference between these (and all other languages)? All they are the same. Just syntax https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...
bedros 9y ago
anybody has a good experience using Kotlin to develop android App for real world use
- mehh 9y ago
  Our android team built new version of our app with kotlin with no issues and greater dev satisfaction.
Phrodo_00 9y ago
While kotlin doesn't have random symbols as operators, it does have inline functions, which look pretty good too, and are especially useful when designing DSLs.
- sixbrx 9y ago
  I'm guessing you meant "infix".
  - Phrodo_00 9y ago
    Yep, I actually looked at the docs to confirm before posting but somehow ended up typing something completely different...
vikiomega9 9y ago
"Be aware, however, that inlining duplicates the function body at each call site, so heavy use of the ‘inline’ keyword can cause your code to grow out of control." I didn't quite understand this part. If the code is being inlined on compilation does it matter? I'm assuming the comment meant the output jar file?
- arwhatever 9y ago
  I think it just means that a unique binary representation of the inlined code gets created and embedded into the compilation output for each usage of the inlined code, which can then cause the compiled output to expand in size.
  - vikiomega9 9y ago
    This hardly sounds like a disadvantage considering deployment sizes most setups have in production anyway.
TheGrassyKnoll 9y ago
Steve Yegge likes Kotlin... http://steve-yegge.blogspot.com/ http://steve-yegge.blogspot.com/
- agumonkey 9y ago
  from may 2017 http://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-than-whatever-dumb.html http://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-... (just in case he writes a new article)
Randgalt 9y ago
What isn't mentioned is the tooling. The Scala compiler and sbt are atrocious. If you move to Scala you'd better get the most massive machine you can find and be prepared to deal with the monstrosity that is sbt.
mathw 9y ago
I don't think the number of Stack Overflow questions is a good indication. Given the difference in age and Scala's use of features unfamiliar to many programmers I'd expect it to generate more questions from (for example) people switching from Java, especially since those unfamiliar features are probably only known to people like Haskell developers who are rare bunch themselves. Kotlin being a bit more of a "Java done right", a bit less radical, maybe generates less confusion. It might also be a sign of Kotlin's documentation being better. I thought the article was pretty weak, it doesn't really go into much detail into how things like higher-kinded types actually affect Scala programming and why you might miss them (or not) in Kotlin, but does take the time to note that Kotlin needs an extra keyword on the constructor arguments for data classes, something which is almost completely irrelevant (and, IIRC, comes from Kotlin's primary constructor syntax so is a reuse of a more widely applicable pattern). I don't think I could come away from this with an idea of which one I should learn and use, as it claims.
cryptos 9y ago
I see a clear pro Scala tendency in this article. Take for example this statement: > In addition, Scala includes features that you won’t find in either Kotlin or Java, such as full support for pattern matching, macros, and higher-kinded types, which makes Scala ideal for big data processing tasks such as: graph analysis, aggregation computations, and complex, mathematically-focused modelling (e.g. medical modelling.) This statement is unfortunately not backed by any explanation. Kotlin has less Stackoverflow questions, but there is also less need for explanation. Limited operator overloading in Kotlin is a good thing! I've seen way to many Scala with completely absurd and unreadable opertors. Having worked with both Kotlin and Scala, I see Kotlin as much more pragmatic, what means real world suitable. While Scala was engineered with programming language research in mind (not an ivory tower language like Haskell, though), Kotlin considers more practical aspects like tool support or long-term maintainability. The Scala compiler is, for example, relatively slow. And what about binary (in)compatility in Scala? No word in the article. What about the imminent breaking change with Scala 3 (aka Dotty)? Scala macros are problematic for tool support. Kotlin will probably get some kind of tool friendly meta-programming, but deliberately not macros. > Kotlin may be widely considered the easier language to learn, but if it doesn’t have all the features you need, then those few hours spent familiarizing yourself with the Kotlin syntax was time that you could have spent starting to learning a language that does give you the functionality you need. That may be true for some features, but Scala is a pretty complex beast with many advanced features, which are not only hard to learn, but which also make the code hard to understand or modify. Think of implicit conversions, implicit parameters, which can make it hard to understand what is going on by looking at the code. Kotlin is much more readable in general: constructos are just named `cunstructor`, init blocks are called `init`, variadic argument are called `vararg`, annotations for co- and contravariance are called `in` and `out`. Scala has to offer method signatures like the following: flatten[U](implicit ev: <:<[T, Try[U]]): Try[U] Don't get me wrong, I don't want do condemn Scala and like it in principle, but I think that Kotlin is the better choice in most cases.
- AzzieElbab 9y ago
  This is actually a very good example how scala can make simple things look confusing by trying extra hard to make things look simple. In reality this code simply means that compiler needs to know how to convert T into a Try[U], but the abstraction looks leacky and confusing, partially because it exposes compiler generxated typeclass <:<: On the other hand, it never fails to amaze me how java users who are willing to accept the magic of java frameworks get so worked up over scala's presumed complexity
xaduha 9y ago
Scala is a non-starter for a lot of people, especially in Android development. Kotlin is much better than Java and that is good enough for me.

94 points by dserban 9y ago

> good fit for any projects where you want to combine these two programming styles. I'm always a bit wary of this. Its difficult to write a big code base in two different styles, I prefer a language that is mainly in one style. am I wrong?

nine_k 9y ago
Sometimes you don't write a project all by yourself, and have critical parts of it already written by completely different people years ago. In a situation like that, the ability to combine two styles with a relatively low impedance mismatch is very valuable.
Sophistifunk 9y ago
I find objects are excellent for... well, objects. Things with private state and behaviour. Services, GUI components, and the like. Functions and records are excellent for business data and the transformations of business data. ¿Por que no los dos?
stickfigure 9y ago
Write an immutable object with methods that return a new (changed) immutable object. Boom, you're an Object-Oriented Functional Programmer.
jackmott 9y ago
I sure don't want immutable linked lists everywhere
naasking 9y ago
> Its difficult to write a big code base in two different styles, I prefer a language that is mainly in one style. Not all problems are amenable to a single paradigm. Functional idioms are well suited to composing small systems, object-like abstraction is well suited to composing large systems and services. Note, object-like, not necessarily object-oriented in the Java sense.

kmizu 9y ago

It is very fair comparison than other "Kotlin vs. Scala" articles.

anorwell 9y ago

I've never used kotlin, but after reading the article, I wondered how it could be possible for kotlin to be null-safe and interoperable with Java at the same time. Turns out it's not [1]. Kotlin's null vs non-null types seem to be semantically the same as option vs non-option (as in scala). However, Scala allows any variable to be null separately from the type system, whereas Kotlin does not. It's not clear to me that Kotlin's approach is preferable here. Kotlin code that interfaces with Java gives the illusion of null-safety, but won't actually provide it. Scala does not attempt to provide this guarantee, which I don't think any language that interoperates with java can ever provide. [1] https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html

bluejekyll 9y ago
This might be a better link based on your concern: https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types https://kotlinlang.org/docs/reference/java-interop.html#null... This feels like a trad-off between ease-of-use/adoption. It's effectively undefined behavior to reference a nullable type from Java. Another way to consider this is that it's not necessarily worse than working natively in Java, but it can over time be better. This trade-off seems reasonable, as there is no great answer to this problem, but it's almost identical to Java's auto-unboxing of Integer types to int.
vbezhenar 9y ago
You can annotate Java code with @Nullable annotations. Kotlin will understand it and interop will be safe. Spring does it for example, AFAIK Guava does it as well. It won't work with Scala. Another advantage over Scala is that Kotlin compiler puts null checks on boundaries between Java and Scala, so even if your code pretending to be safe breaks in runtime, you'll catch error as soon as possible, this null won't leak into your internals to bite you tomorrow. But that's certainly a thing that could be improved. Majority of Java parameters/return values nullability could be automatically inferred by analyzing bytecode.
- dep_b 9y ago
  Interesting. A bit worse than Swift and Objective-C. Objective-C has to promise `nonnull` otherwise it's shown as `ObjectType!` which basically means we treat it as non-null but it could be null and can be checked for null. Methods marked `nonnull` can still be nil sometimes, it's just a promise. Hard bugs to fix. Found one in an Apple framework where I could not think of anything else than comparing the address with 0x00000000 to see if it was nil.

pron 9y ago

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 http://dl.acm.org/citation.cfm?id=620728

jonathanapp 9y ago
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.
- cutler 9y ago
  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.

jgrant27 9y ago

The article seems to paint Kotlin as not really much of a functional language as Scala is but more of a Java replacement. This is just not true. Both languages will not stop you from writing imperative code just as much as either can be used for a very functional style of programming. It really comes down to the caliber of developer and not the language choice here.

foolfoolz 9y ago
seems very elitist to say functional vs imperative depends on the caliber of the developer. there's plenty of reasons to choose either paradigm. language choice is a reasonable factor. just because you like OO doesn't mean you are bad and just because you like functional doesn't mean you are good
- jackmott 9y ago
  what if my object has first class functions as all of its members? i am then bad and good?
  - foolfoolz 9y ago
    you're a few thousand unit tests away from web scale
- jswizzy 9y ago
  I think OO when done right looks very much like FP. The problem is that OOP is just as hard as FP to write since most languages that claim to be OO languages are actually heavily procedural in nature.

guelo 9y ago

I thought the article was very light on details and lacking some important bits. This one is I think a better comparison at the language level: https://agilewombat.com/2016/02/01/scala-vs-kotlin/ https://agilewombat.com/2016/02/01/scala-vs-kotlin/

souenzzo 9y ago

What is the difference between these (and all other languages)? All they are the same. Just syntax https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...

bedros 9y ago

anybody has a good experience using Kotlin to develop android App for real world use

mehh 9y ago
Our android team built new version of our app with kotlin with no issues and greater dev satisfaction.

Phrodo_00 9y ago

While kotlin doesn't have random symbols as operators, it does have inline functions, which look pretty good too, and are especially useful when designing DSLs.

sixbrx 9y ago
I'm guessing you meant "infix".
- Phrodo_00 9y ago
  Yep, I actually looked at the docs to confirm before posting but somehow ended up typing something completely different...

vikiomega9 9y ago

"Be aware, however, that inlining duplicates the function body at each call site, so heavy use of the ‘inline’ keyword can cause your code to grow out of control." I didn't quite understand this part. If the code is being inlined on compilation does it matter? I'm assuming the comment meant the output jar file?

arwhatever 9y ago
I think it just means that a unique binary representation of the inlined code gets created and embedded into the compilation output for each usage of the inlined code, which can then cause the compiled output to expand in size.
- vikiomega9 9y ago
  This hardly sounds like a disadvantage considering deployment sizes most setups have in production anyway.

TheGrassyKnoll 9y ago

Steve Yegge likes Kotlin... http://steve-yegge.blogspot.com/ http://steve-yegge.blogspot.com/

agumonkey 9y ago
from may 2017 http://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-than-whatever-dumb.html http://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-... (just in case he writes a new article)

Randgalt 9y ago

What isn't mentioned is the tooling. The Scala compiler and sbt are atrocious. If you move to Scala you'd better get the most massive machine you can find and be prepared to deal with the monstrosity that is sbt.

mathw 9y ago

I don't think the number of Stack Overflow questions is a good indication. Given the difference in age and Scala's use of features unfamiliar to many programmers I'd expect it to generate more questions from (for example) people switching from Java, especially since those unfamiliar features are probably only known to people like Haskell developers who are rare bunch themselves. Kotlin being a bit more of a "Java done right", a bit less radical, maybe generates less confusion. It might also be a sign of Kotlin's documentation being better. I thought the article was pretty weak, it doesn't really go into much detail into how things like higher-kinded types actually affect Scala programming and why you might miss them (or not) in Kotlin, but does take the time to note that Kotlin needs an extra keyword on the constructor arguments for data classes, something which is almost completely irrelevant (and, IIRC, comes from Kotlin's primary constructor syntax so is a reuse of a more widely applicable pattern). I don't think I could come away from this with an idea of which one I should learn and use, as it claims.

cryptos 9y ago

I see a clear pro Scala tendency in this article. Take for example this statement: > In addition, Scala includes features that you won’t find in either Kotlin or Java, such as full support for pattern matching, macros, and higher-kinded types, which makes Scala ideal for big data processing tasks such as: graph analysis, aggregation computations, and complex, mathematically-focused modelling (e.g. medical modelling.) This statement is unfortunately not backed by any explanation. Kotlin has less Stackoverflow questions, but there is also less need for explanation. Limited operator overloading in Kotlin is a good thing! I've seen way to many Scala with completely absurd and unreadable opertors. Having worked with both Kotlin and Scala, I see Kotlin as much more pragmatic, what means real world suitable. While Scala was engineered with programming language research in mind (not an ivory tower language like Haskell, though), Kotlin considers more practical aspects like tool support or long-term maintainability. The Scala compiler is, for example, relatively slow. And what about binary (in)compatility in Scala? No word in the article. What about the imminent breaking change with Scala 3 (aka Dotty)? Scala macros are problematic for tool support. Kotlin will probably get some kind of tool friendly meta-programming, but deliberately not macros. > Kotlin may be widely considered the easier language to learn, but if it doesn’t have all the features you need, then those few hours spent familiarizing yourself with the Kotlin syntax was time that you could have spent starting to learning a language that does give you the functionality you need. That may be true for some features, but Scala is a pretty complex beast with many advanced features, which are not only hard to learn, but which also make the code hard to understand or modify. Think of implicit conversions, implicit parameters, which can make it hard to understand what is going on by looking at the code. Kotlin is much more readable in general: constructos are just named `cunstructor`, init blocks are called `init`, variadic argument are called `vararg`, annotations for co- and contravariance are called `in` and `out`. Scala has to offer method signatures like the following: flatten[U](implicit ev: <:<[T, Try[U]]): Try[U] Don't get me wrong, I don't want do condemn Scala and like it in principle, but I think that Kotlin is the better choice in most cases.

AzzieElbab 9y ago
This is actually a very good example how scala can make simple things look confusing by trying extra hard to make things look simple. In reality this code simply means that compiler needs to know how to convert T into a Try[U], but the abstraction looks leacky and confusing, partially because it exposes compiler generxated typeclass <:<: On the other hand, it never fails to amaze me how java users who are willing to accept the magic of java frameworks get so worked up over scala's presumed complexity

xaduha 9y ago

Scala is a non-starter for a lot of people, especially in Android development. Kotlin is much better than Java and that is good enough for me.