Hacker News Reader

Comment by davidcaseria | Hacker News Reader

Looking at the syntax briefly it seems very similar to Scala. Is there any major differences between Scala and Kotlin?

Kotlin has a much simpler syntax, and much simpler semantics, than Scala. Specifically, it's largely a very, very good syntax, and small class library extension, for otherwise-vanilla alternative syntax to Java.

This is the whole reason for its existence: Kotlin code cleanly interoperates, in both directions, with existing Java code. From my own experience, this means that it's very easy compared to Scala to introduce into an existing code base: you can sanely go class by class, file by file, cleaning up code, relying on the existing unit tests, without breaking anyone's workflow. As a result, it has, in my experience, proved a lot cheaper than Scala to train new devs in it as well.

That's not to say that it's all just syntax, though. Kotlin also brings null safety, traits, builders, and some other key things over from the Scala, Groovy, other sources, which has proven to be a major productivity boost. Its collections library is a lot saner (IMHO) than Java 8's due to better generics support. It adds data types and value semantics for when you need them as well. But it does so in a way that (again, based on experience introducing Kotlin into a company after Scala had failed to gain any traction) is a lot easier to teach to most developers, and a lot easier to integrate into existing workflows.

Just to clarify, Kotlin doesn't have a collections library. What it does have is some clever compiler magic over JDK collections that adds:

• Mutable vs immutable views (List is read only, MutableList is read/write)

• Safer generics: map[key] which is translated to map.get() has the type bound you would expect rather than Java's much weaker Object type.

• Lots and lots of extension functions to do things like functional programming with them

However, behind the scenes they are still JDK collections, so you can call to and from existing Java with no problems and ... you know, actually, JDK collections library is pretty good. Especially once you get into the scalable concurrent collections.

Eh, I get why my phrasing might make it sound like they had a totally separate collections hierarchy; you're right, they don't. But I'd count the changes you list--especially the extension methods, which basically provide an entire Java 8-streams-like API that runs comfortably on top of even Android's superannuated Java--as a collections library in its own right. (Hell, even the fixes they do at the compiler level to maps makes the entire collections API feel a lot more like .NET, with its reified generics, and a lot less like Java's weird situation.)

There are many feature-level differences, but the biggest differences are in the approach, goals and philosophy[1].

When it comes to philosophy, Kotlin is a modern Java -- i.e. a "blue-collar" language[2], aiming to adopt only tried-and-true ideas and not to break new grounds. Scala is most certainly not blue-collar, serving as a basis for a few PhDs, and incorporates many ideas that haven't been tried in the industry. Scala is adventurous; Kotlin tries hard not to be.

When it comes to goals, Kotlin aims to solve Java's pain points (nulls, properties, beans) while keeping the same libraries. Kotlin doesn't even have much of a runtime library to speak of. A Java library is an idiomatic Kotlin library, and is almost indistinguishable from Kotlin libraries when used from Kotlin (i.e., no limited functionality, no wrappers needed). Kotlin's design is built around this core idea. While Scala interoperates with Java, it has its own runtime library, and many types (e.g. collections) need to be wrapped when passed across languages.

When it comes to approach, Kotlin is developed hand-in-hand with its tools (IDE, build, multi-lang compilation), and made to be gradually adopted into Java codebases. You can easily mix Kotlin and Java classes in the same package (the IDE will even convert any given Java class to a Kotlin class, and seamlessly handle mixed-language codebases). Scala and its tools are developed separately, and it's built to be independent of Java (although it interoperates with it). Another difference in approach (although it's still theoretical so not quite fair) is that the Koltin dev promise that the language will be source and binary backwards-compatible starting with the imminent version 1.0 (though this promise hasn't been put to the test), while Scala allows for occasional breaking changes.

[1]: Java and C have very similar syntax, yet the two are completely different (although Kotlin and Scala are probably more similar to one another than Java and C).

[2]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....

You keep spreading your misinformed FUD about scala every time someone mentions it in a thread. Do you really continue to maintain the position that scala is not used successfully by large teams?

Are you responding to the right post? Because the post above yours doesn't say anything about that.

Pron tends to zealously defend Java and Kotlin and bash pretty much anything else, especially Scala, but his post here today seems perfectly reasonable.

The only thing that seems to be spreading is the use of the word FUD as well as personal attacks by some people who think they should be rude to those they disagree with. A few conditions have to be met in order for a statement to qualify as FUD: 1/ It has to be false or at least grossly inaccurate, 2/ its falsehood/inaccuracy has to be intentional, and 3/ it has to be negative. My statements fulfill none of those conditions, so relax. It's been a long time (well over a year, if not two, IIRC) since I discussed my bad experience with Scala or said anything negative about it, and for the record, I have never said that Scala is not used successfully by large teams, only that I have had a very bad experience adopting Scala in a large team, an experience shared by other such teams, and that I believe it may not be a good choice in such circumstances. My opinions are neither overly negative nor uncommon, the only difference is that I was foolish enough to sound them in spite of the rampant rudeness of some who for whatever reason took personal offense. I have also repeatedly said that I realize that that experience isn't universal.

Also, I would appreciate you stop saying that my opinions are misinformed (as they are most certainly not), unless you care to point out my errors. It's OK to disagree, and I don't think you should expect everyone to share the same opinions with you.

BTW, I think that much of the (valid) disagreement stems from a difference in perspective. Some people concentrate on language features, while I could care less whether a language has higher-flavored emojis or subliminal piping. I view those features as means to an end, so first and foremost I care about that end -- what the language aims to achieve -- long before getting to how it aims to achieve it, which, IMO, is only a concern once the goals match your own, otherwise the discussion is purely academic (which may be interesting in its own right, but not my focus).

https://kotlinlang.org/docs/reference/comparison-to-scala.ht...

I'd say the syntax is halfway in between Java and Scala. That makes it much more approachable for Java developers (you can learn the basics in an afternoon), but also less flexible than Scala sometimes.

Yeah, Kotlin looks largely like a simpler, stripped down version of Scala. It's a lot closer to Scala than it is to Java, but it's close enough to Java devs to not have to put in much effort to learn vs learning Scala. I prefer Scala, but not everyone wants to invest the time to learn it in order to gain maybe 25% more expressiveness. Kotlin also seems like a better fit for Android than Scala (and Java for that matter).

In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).

Not everything in Scala can be cleanly translated into Java, but Kotlin looks more like a subset of Scala than it does a superset of Java. The syntax is very close.

i'll wager a guess: kotlin compiles faster.

Much faster. So very much faster. I won't trade off so many features for compile speed as to make Go seem like a good idea, but Kotlin is hitting a really nice balance for me between Java and Scala on the feature/iteration-loop front.

Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.

https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a

I agree. One thing that is sorely missing, for example, is a way to define recursive values.

In Scala, to express a recursive parser combinator:

val e = p | e

You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.

Wow can you really write

    val e = p | e

in Scala? How does that work with eager evaluation?

It's not eager. The | combinator takes lazy parameters (called pass-by-name in scala). So it essentially gets translated to:

val e = operator_pipe(() => p, () => e)

Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.

(disclaimer: I think Kotlin is cool)

And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.

It's not that hard to implement your own stream abstraction.

Kotlin does have lazy map/reduce/filter: those are available through the Sequence interface.

It's very limited. Many of the functions you use when operating with collections also return lists, not sequences.

Sequence has much the same extensions available on it as other collections.

I did a tutorial a week or so ago (it's not online yet, unfortunately) on FP in Kotlin. We wrote a little app to do IntelliSense style autocompletion on an n-gram model. The core code was purely functional and used lazyness as well.

I suspect "does Kotlin support FP" is one of those questions that's doomed to turn into a no-true-scotsman thing: whatever support is available will be considered insufficient by true FP fans :-) But it's good enough to let you write code in a typical functional style in many cases, with little cost.

Which is mostly what used to be, 10 years ago. Closures, map, fold, etc. Before Haskell and Clojure like immutability and extra trimmings became fashionable...

In 1995 or even 2000 era LISP discussions you rarely if ever see those other concerns about FP that hipster functional programmers bring forward today.

(I guess it's also something that was helped by Moore's Law style speed development slowing down and the advancements in multicores...)

FP doesn't even have a definition (though pure-FP does, but it, too, can be a bit ambiguous and depends on how you define effects). FP is mostly accepted to be those patterns practiced by people in the FP community. I heard someone deeply involved with FP say, "FP is more a community than a well-defined programming style".

Quite right, back on those days FP was Smalltalk (yes really), Scheme, Common Lisp, Emacs Lisp, Caml Light (no OCaml yet), Standard ML and Miranda (no Haskell yet).

Which like you mention is where I point those hipsters to.

Then again, all new generations think they know best.

Language evolves; "FP" today means something different from what it meant 10 years ago. There's no need for dismissiveness in either direction.

Reply on news.ycombinator.com