4 ms·
I don't use scala, I've played around with it a bit. The question I have when reading though this is, why would I use Kotlin instead of Scala? Can anyone after
by spooneybarger 15y ago
I don't use scala, I've played around with it a bit. The question I have when reading though this is, why would I use Kotlin instead of Scala? Can anyone after reading about Kotlin lay out where the really large differentiators are that would seriously sway someone one way or another?
- mike_esspe 15y agoHere is a comparison: http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala http://confluence.jetbrains.net/display/Kotlin/Comparison+to... Personally, i don't see a convincing reason to switch. Though absence of type erasure is nice
- spooneybarger 15y agoI'm not really swayed by comparisons that include things like: 'Complicated logic for initialization of traits'. Does Kotlin have traits or something similar? If yes, are they complicated to initialize? If not, then does it matter as a point of comparison that Scala has something that might be complicated if Kotlin offers nothing comparable? I'm really mostly working from a high level of ignorance here.
- bad_user 15y agoDude, read the fucking docs before passing judgment. http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... Basically the language has no notion of interfaces; preferring instead multiple inheritance. Then the diamond problem is taken care of by making mandatory the overriding of conflicts. See the provided example: http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-Diamondinheritance http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... Then, it also has syntactic sugar for the Delegation pattern: http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-Delegation http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... One cool thing about Scala's implicit conversions is that they eliminate many use-cases which would make you use traits. Kotlin has a similar mechanism, but kind of different (taken from C#); extension methods: http://confluence.jetbrains.net/display/Kotlin/Extension+functions http://confluence.jetbrains.net/display/Kotlin/Extension+fun... The classic trait I'm thinking about when thinking about traits is the Enumerable module in Ruby: http://www.ruby-doc.org/core/classes/Enumerable.html http://www.ruby-doc.org/core/classes/Enumerable.html This is a classic example of where a trait is useful for providing common implementation for collections that only have to implement "each". The cool thing about extension methods is that you can implement all those methods in the Enumerable module above, without dealing with multiple inheritance or traits. The difference between implicit conversions and extension methods is that implicit conversions are more flexible, but extension methods are easier to reason about and (being statically resolved at compile-time) don't suffer from performance penalties. I'm not saying that what Kotlin does is better than Scala, but it does seem simpler. Personally I can't wait to play with it.
- aneth 15y agoI particularly like their much simpler approach to null-safety. Null is a ghost that haunts every imperative language, and it's great to see a good solution. Scala's is also nice, but wordy and difficult for newbies. Simply being able to call a method chain without null checks or pattern matching is really nice. In Kotlin, you can either declare the variables non-nullable or use a safe call chain, e.g. kennel?.mommies?.puppies() http://confluence.jetbrains.net/display/Kotlin/Null-safety http://confluence.jetbrains.net/display/Kotlin/Null-safety