3 ms·
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
by 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 agoThis 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