Hacker News Reader

Comment by spooneybarger | Hacker News Reader

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?

View on HN

Here is a comparison: 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

I'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.

Dude, read the fucking docs before passing judgment.

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+I...

Then, it also has syntactic sugar for the Delegation pattern:

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+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

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.

I 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

Reply on news.ycombinator.com