Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've played a bit with Kotlin and have a much better knowledge of Scala, so I could be biased. I like Kotlin, it looks like Java should look like. Kotlin is "just" a better language and not a complete new World like Scala. In Scala it feels often wrong to use a Java lib instead of a Scala lib. So, Kotlin is a smooth upgrade for all Java developers.

But Scala is much, much more powerful than Kotlin. Just look at Scala Traits for example. I think, if you have good developers who are willing to learn and to improve, you can get more out of Scala. If you're not that lucky (and I think that is the usual case), you maybe better off with Kotlin.



Traits seem like an odd feature to pick. What are you thinking of, precisely? Kotlin interfaces are basically the same: they can contain method and property impls (same as Java 8). Do Scala traits have some additional feature I am unaware of?

I admit to a little bias: I've tried to get into Scala several times, but the bad documentation and often overly complex approach puts me off. A lot of Scala features seem like workarounds for other features sometimes. For instance value types in Scala have so many restrictions that they are barely value types at all (e.g. they can have only one member!) and so their primary use case appears to be implementing overhead free extension methods. But Kotlin supports extension methods directly. So whilst implicits+value types may appear to be two features that Kotlin lacks, when you boil it down, it turns out that it has simpler and faster approaches to the same thing.

That said, real value classes (with JVM support) will be good when they arrive.


Kotlin interfaces are essentially the same as Java interfaces. But Traits in Scala are more like (slightly) restricted multiple inheritance. They can have fields, they can be stacked (http://www.artima.com/scalazine/articles/stackable_trait_pat...), you can restrict the types where a trait can be mixed in.

Value types are useful to enforce certain types which helps to avoid million dollar mistakes like the NASA made when mixing inch and meter as simple floating point numbers.

All in all I think, that Kotlin is a good example of the 80:20 rule. You get the most useful concepts and convenience with a low investment. Maybe Kotlin hits a sweet spot in the JVM landscape.


"Kotlin interfaces are essentially the same as Java interfaces." Interfaces in Kotlin offer functionality beyond interfaces in Java. In Java interfaces can only have public methods. In Kotlin interfaces can also have (abstract) variables. Both, methods and vars, in Kotlin interfaces can be public and also protected. You need this if you don't want to break the encapsulation of your classes that implement an interface.


Yes, being able to define numeric units is a helpful feature indeed.


I think you are missing the motivation behind some of these things:

Oracle would probably never have started to experiment with value types and specialized generics, if Scala didn't take the plunge and implemented, tested and shipped it years ago already.

Of course there are restrictions... but the choice was basically either never getting value types and generics, or accepting some restrictions until Scala drags Java into the 1990ies.

It's the same with extension methods. If the only thing you ever knew where extension methods, they would look pretty exciting. But after being aware of the full range of approaches, extension methods are "meh" ... they only implement the least useful part of implicits.

If I had to decide between extension methods and nothing, I'd pick nothing. Extension methods are just not pulling their weight.

Scala does a lot of things in a certain way, because the have > 10 years of experience experimenting with various approaches.

I suggest that you try to understand _why_ Scala does things this way, instead of assuming Scala devs are stupid. It's pretty likely that everything Kotlin does has been considered by Scala developers 5 years ago already–and discarded because better designs were discovered.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: