11 ms·

The Kotlin Language: 1.0 Beta Is Here

178 points by TheAnimus 11y ago

davidcaseria 11y ago
Looking at the syntax briefly it seems very similar to Scala. Is there any major differences between Scala and Kotlin?
- baq 11y ago
  i'll wager a guess: kotlin compiles faster.
  - eropple 11y ago
    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.
- axelfontaine 11y ago
  https://kotlinlang.org/docs/reference/comparison-to-scala.html https://kotlinlang.org/docs/reference/comparison-to-scala.ht...
- alfongj 11y ago
  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.
  - jinst8gmi 11y ago
    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).
    - justthistime_ 11y ago
      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).
      - jinst8gmi 11y ago
        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.
- gecko 11y ago
  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.
  - mike_hearn 11y ago
    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.
    - gecko 11y ago
      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.)
- whateveracct 11y ago
  Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.
  - pron 11y ago
    https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a
  - hrjet 11y ago
    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.
    - chrisseaton 11y ago
      Wow can you really write val e = p | e in Scala? How does that work with eager evaluation?
      - hrjet 11y ago
        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.
  - edgyswingset 11y ago
    (disclaimer: I think Kotlin is cool) And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.
    - icholy 11y ago
      It's not that hard to implement your own stream abstraction.
- deleted 11y ago
  [deleted]
- pron 11y ago
  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.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....
  - runT1ME 11y ago
    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?
    - incepted 11y ago
      Are you responding to the right post? Because the post above yours doesn't say anything about that.
programminggeek 11y ago
I've used both Kotlin and Scala a bit and for some very specific message passing/protocol tricks, Scala was able to let me do what I wanted more than Kotlin. That was maybe 6-12 months ago, so I'm not sure if that has changed. That said, there is something pretty cool about Kotlin that I like. Congrats on 1.0 Beta.
kcorbitt 11y ago
I've been using Kotlin on Android for about six months, and can't recommend it highly enough. If you're stuck in the Java ecosystem, Kotlin will make your life much better. I also recommend it for people coming from the world of dynamic typing (Ruby, Javascript, Python, etc.). If you can appreciate the guarantees of a static type system -- and I submit that anyone who has worked on a project of more than a few KLOC can -- give Kotlin a try. It's much less verbose than Java, and gives you the tools and constructs to program in much the same style as you would in a dynamic language, but with extremely good compile-time correctness checks. It may not be Haskell, but it's pragmatic, practical and productive. The tooling is also world class, as you might expect from a language developed by JetBrains. I recommend using Kotlin with IntelliJ -- the intellisense is guaranteed to boost your productivity. Seamless Java interop has been a huge priority for the developers, so the ecosystem is also quite good. Its biggest weakness (for my use case anyway) is the lack of a good, modern web framework. Hopefully now that Kotlin is more stable a native library ecosystem will emerge that plays to Kotlin's strengths more than Java's.
- Nilzor 11y ago
  How does it affect built time and the feedback cycle?
  - jinst8gmi 11y ago
    Build times are supposed to be comparable to Java.
    - dodyg 11y ago
      It's slower.
      - mike_hearn 11y ago
        It depends how you use it. At the moment the gradle plugin doesn't do incremental compilation. If you use it for Android, that's an issue because of the Android build system. I use Kotlin for free standing programs that run on my laptop/desktop. In these cases it's about as fast as Java, but that's because IntelliJ controls the compilation itself and gradle/maven is used only rarely.
pjmlp 11y ago
It would be sweet if it already had a CoreCLR backend. Portable code between WP and Android without JNI pain.
- kodablah 11y ago
  They have taken steps to separate (most) of the frontend and the backend and will be resuming work on the JS side after 1.0. While I haven't dug into the internals very much, it seems with the concept of "platform types" (i.e. implicitly nullable) and not having anything too JVM-specific, CLR support might be an approachable project for the community. I recommend the community take it and keep it up to date with pre-releases of Kotlin. With ScalaCLR IIRC, when Typesafe decided to stop supporting it it basically withered as new Scala features were rapidly developed. It also has a better chance than ScalaCLR due to how small the runtime is. But, like Swift with ObjC, since the runtime is so small so many of the libraries are going to targer the JVM and reference JVM libs which may make the cross-VM ecosystem non-existent (doesn't mean it still won't have good CLR uses of course).
  - pjmlp 11y ago
    That is my view as well. But having platform specific code hidden behind interfaces is way saner than having to write JNI for almost every framework API when using C++ for business logic. The problem doesn't happen in the other mobile OSes thanks to Objective-C++ and C++/CX. My current approach.
  - yole 11y ago
    Right now developing a new backend for Kotlin is much harder than necessary because the compiler doesn't have any IR and any desugaring passes - in other words, each backend has to work directly with the full AST (annotated with types etc., but still using all language constructs). We plan to rework this post-1.0, after which building a new backend will be much more feasible.
platz 11y ago
are non-exhaustive pattern matches in kotlin warnings, errors, or neither? looks like from the docs: "If `when` is used as an expression, the `else` branch is mandatory, unless the compiler can prove that all possible cases are covered with branch conditions." So it is an error, I assume?
- kcorbitt 11y ago
  With the caveat that I haven't tried it myself: > What about pattern matching? This is where the word “sealed” above comes in handy; we can do an exhaustive pattern match without an else/otherwise branch from https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a#.8dbwaz4yi https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a#.8dbwa...
  - commentzorro 11y ago
    This looks to be single value matching only and no compile time exhaustion checks. This looks like really nice (i.e. sugary) alternative to switch but not quite pattern matching.
- udalov 11y ago
  It's an error only when the 'when'-expression is used as a value, like assigned to a property, passed as an argument or returned from a function. Otherwise it's not an error. There's also a warning for matching enum values over an incomplete set of enum entries, but otherwise non-exhaustive 'when'-expression is green code. You can basically consider 'when'-expressions to be syntax sugar over Java's if-else or ternary operator (?:) chains.
  - platz 11y ago
    > non-exhaustive pattern matches So there are no non-exhaustive pattern matches, is what you are saying? i.e. they all must be exhaustive. Except for your enum example
    - udalov 11y ago
eropple 11y ago
I've been using Kotlin for a little while, as the backend language for the side project/maybe-startup I'm working on. I went with it because of my troubling tendency to write Scala code I can't read three weeks later, and in that I think Kotlin's a big success: the Java interop is good (still some weirdness around DI frameworks and non-nullable types, which is unavoidable if you're using something like Jersey with HK2), the language itself has most of the niceties I want, and I find that the tooling is really pretty good in general. And the Kotlin community, in my experience, has been really good (aside from...sigh...yet another Slack chat to be in), unlike the continuing and perpetual disaster of Scala whenever certain members of the This Should Be Haskell mafia are allowed near anyone who's just asking a question. I miss things from Scala once in a while, but they're usually me being way too cute with my code anyway--good for tiny personal things, not for something I'm hoping I'm looking at three years from now, not just three weeks from now.
- wpietri 11y ago
  That's helpful. I have this side Scala project, a long-lived daemon[1], that I've been meaning to rewrite in something else, as I've grown disenchanted with it. (Bruce Eckel and Paul Phillips contributed to that. [2]) But every alternative I could think of was not so appealing. I'll check this out. [1] https://github.com/wpietri/sunrise https://github.com/wpietri/sunrise [2] https://news.ycombinator.com/item?id=10163446 https://news.ycombinator.com/item?id=10163446
vbezhenar 11y ago
I tried Kotlin in one small project, which used Java API and I can recommend it. There are a lot of handy features there. There were quite a bit of breaking changes, but, of course, it's expected from unreleased language. It wasn't hard to fix things. For me Kotlin is in sweet spot between verbose Java and complex powerful Scala. From a practical point of view, I would prefer it to both. Any competent Java programmer will catch Kotlin fast enough, and it has almost anything I would want from a "improved Java" language.
merb 11y ago
it would be great if playframework also had kotlin support. The problem here is that kotlin has no sbt support.
- strictfp 11y ago
  Is Play any good these days? Tried it when it was new, was an utter mess. Found a couple of bugs within the first hour or so...
  - whateveracct 11y ago
    I know that Play 2 is happily used in production all over the place. I'm guessing it's a lot better than when you used it.
  - merb 11y ago
    we still hit a great but since we support legacy printer devices on our applications which using ssl over a custom certificate which changes over every printer. So we would need to have a function that accepts any cerificate inside the ws-client of play. unfortunatly the acceptAllCerts doesn't work in play 2.4+. however we didn't hit more bugs, yet and using it since 2.1
smithkl42 11y ago
Kotlin seems to fill a niche comparable to TypeScript: a language that doesn't try to break new ground, but picks a bunch of tried-and-true ideas to fix severe problems in the underlying platform. Like TypeScript, I hope that it ends up being the right language, with the right compromises, at the right time.
- dodyg 11y ago
  Yup. It helps that Kotlin is also a smallish language. You can pick it up in a day.
Drup 11y ago
Comparison with Ceylon ?
- thom_nic 11y ago
  Here's a preso: https://speakerdeck.com/evacchi/kotlin-and-ceylon-modern-programming-languages-for-a-modern-jvm https://speakerdeck.com/evacchi/kotlin-and-ceylon-modern-pro... I can't say I've used Ceylon much but I think Kotlin's syntax is much nicer and it's much easier to approach than Scala.
  - mercurial 11y ago
    I'd imagine having Jetbrains behind Kotlin means much better tooling, which is likely to be more important for a lot of people than language features like ADTs.
  - evacchi 11y ago
    to be fair, I presented that before Kotlin hit 1.0. A few things that I liked are no more (like the @-less syntax for annotations). But all in all I believe it is still a good commentary.
  - deleted 11y ago
    [deleted]
nikolay 11y ago
How is it better than Ceylon 1.2? Ceylon compiles to JVM bytecode, JavaScript, Dart, and will to LLVM in the future. As a language, it's a great superset of Java. I posted [0] about the great new Ceylon 1.2 (which is backed by Red Hat), and nobody seemed to care, but there's so much hype about Kotlin - I don't get it! [0] https://news.ycombinator.com/item?id=10474126 https://news.ycombinator.com/item?id=10474126
- clumsysmurf 11y ago
  I suspect much of the excitement around Kotlin is coming from Android developers that see the language as their deliverance from Java 6.5.
- commentzorro 11y ago
  Don't know Ceylon or Kotlin except superficial poking around the websites. So, let me ask you, how is Ceylon better than Kotlin? I'd like to see a good write-up (separate blog post) that compares and contrasts the two. What are use cases where one language would be significantly better than the other? (Edit) Wow! Did not expect such a dearth of samples (for both languages) on Rosetta Code. http://rosettacode.org/wiki/Category:Ceylon http://rosettacode.org/wiki/Category:Ceylon http://rosettacode.org/wiki/Category:Kotlin http://rosettacode.org/wiki/Category:Kotlin and only one overlap: http://rosetta.alhur.es/compare/Ceylon/Kotlin/# http://rosetta.alhur.es/compare/Ceylon/Kotlin/#
  - eropple 11y ago
    Given that a strength of Kotlin is that you can dumb-port Java straight to it without even thinking about it, I'm not really surprised it doesn't have much presence on Rosetta Code. It's not the right audience.
- pron 11y ago
  Not better -- different. In my opinion, it's best to read the two language's design goals to understand the difference (as those matter a lot more than any particular feature). The Kotlin design goals are outlined in the blog post, and the Ceylon design goals can be found here[1]. IMO, a TLDR would be: Ceylon attempts to replace not just the Java language but also the standard libraries, while Kotlin intends to upgrade the language only and blend into the existing ecosystem. That difference explains many if not most of the decisions regarding the particular features of each language. [1]: http://ceylon-lang.org/documentation/1.1/faq/ http://ceylon-lang.org/documentation/1.1/faq/ + http://ceylon-lang.org/blog/2012/01/10/goals/ http://ceylon-lang.org/blog/2012/01/10/goals/
EdwardDiego 11y ago
I'm disappointed with the people who are down-voting this comment, as it's, in my opinion, informative and provides a reasonable summation of the differences between Kotlin and Scala. I'd ask people who disagree to put their disagreement into words.
- justthistime_ 11y ago
  He has been told by both Scala _AND_ Ceylon language developers that his large walls-of-texts are wrong and are largely made-up stuff which sounds plausible to him. Somehow he feels like he still needs to recycle his nonsense in every thread regardless of how remotely related it is to the topic.
  - EdwardDiego 11y ago
    So what, in the above "wall of text", is wrong about Scala or Kotlin? You're not telling what was incorrect, just that the author is _always_ incorrect, which strikes me as hyperbole.
    - deleted 11y ago
      [deleted]
    - justthistime_ 11y ago
      So what, in the above "wall of text", is wrong about Scala or Kotlin? Maybe just check the responses from the last fifteen dozen times? It's not that hard. You're not telling what was incorrect, just that the author is _always_ incorrect, which strikes me as hyperbole. I'm not telling anything. The Scala and Ceylon designers did. They probably know better than me, or him.
      - EdwardDiego 11y ago
        > Maybe just check the responses from the last fifteen dozen times? It's not that hard. So you have no valid criticism of the present statement then? Good to know.
bcbrown 11y ago
How easy is it to write Kotlin code for Hadoop mappers and reducers?
bink-lynch 11y ago
I looked around and found a nice writeup on Kotlin: https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3 https://medium.com/@octskyward/why-kotlin-is-my-next-program...
TorbjornLunde 11y ago
Anybody used it compiled to JavaScript? What’s your experience? How does it compare to TypeScript?

178 points by TheAnimus 11y ago

davidcaseria 11y ago

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

baq 11y ago
i'll wager a guess: kotlin compiles faster.
- eropple 11y ago
  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.
axelfontaine 11y ago
https://kotlinlang.org/docs/reference/comparison-to-scala.html https://kotlinlang.org/docs/reference/comparison-to-scala.ht...
alfongj 11y ago
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.
- jinst8gmi 11y ago
  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).
  - justthistime_ 11y ago
    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).
    - jinst8gmi 11y ago
      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.
gecko 11y ago
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.
- mike_hearn 11y ago
  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.
  - gecko 11y ago
    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.)
whateveracct 11y ago
Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.
- pron 11y ago
  https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a
- hrjet 11y ago
  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.
  - chrisseaton 11y ago
    Wow can you really write val e = p | e in Scala? How does that work with eager evaluation?
    - hrjet 11y ago
      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.
- edgyswingset 11y ago
  (disclaimer: I think Kotlin is cool) And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.
  - icholy 11y ago
    It's not that hard to implement your own stream abstraction.
deleted 11y ago
[deleted]
pron 11y ago
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.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....
- runT1ME 11y ago
  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?
  - incepted 11y ago
    Are you responding to the right post? Because the post above yours doesn't say anything about that.

programminggeek 11y ago

I've used both Kotlin and Scala a bit and for some very specific message passing/protocol tricks, Scala was able to let me do what I wanted more than Kotlin. That was maybe 6-12 months ago, so I'm not sure if that has changed. That said, there is something pretty cool about Kotlin that I like. Congrats on 1.0 Beta.

kcorbitt 11y ago

I've been using Kotlin on Android for about six months, and can't recommend it highly enough. If you're stuck in the Java ecosystem, Kotlin will make your life much better. I also recommend it for people coming from the world of dynamic typing (Ruby, Javascript, Python, etc.). If you can appreciate the guarantees of a static type system -- and I submit that anyone who has worked on a project of more than a few KLOC can -- give Kotlin a try. It's much less verbose than Java, and gives you the tools and constructs to program in much the same style as you would in a dynamic language, but with extremely good compile-time correctness checks. It may not be Haskell, but it's pragmatic, practical and productive. The tooling is also world class, as you might expect from a language developed by JetBrains. I recommend using Kotlin with IntelliJ -- the intellisense is guaranteed to boost your productivity. Seamless Java interop has been a huge priority for the developers, so the ecosystem is also quite good. Its biggest weakness (for my use case anyway) is the lack of a good, modern web framework. Hopefully now that Kotlin is more stable a native library ecosystem will emerge that plays to Kotlin's strengths more than Java's.

Nilzor 11y ago
How does it affect built time and the feedback cycle?
- jinst8gmi 11y ago
  Build times are supposed to be comparable to Java.
  - dodyg 11y ago
    It's slower.
    - mike_hearn 11y ago
      It depends how you use it. At the moment the gradle plugin doesn't do incremental compilation. If you use it for Android, that's an issue because of the Android build system. I use Kotlin for free standing programs that run on my laptop/desktop. In these cases it's about as fast as Java, but that's because IntelliJ controls the compilation itself and gradle/maven is used only rarely.

pjmlp 11y ago

It would be sweet if it already had a CoreCLR backend. Portable code between WP and Android without JNI pain.

kodablah 11y ago
They have taken steps to separate (most) of the frontend and the backend and will be resuming work on the JS side after 1.0. While I haven't dug into the internals very much, it seems with the concept of "platform types" (i.e. implicitly nullable) and not having anything too JVM-specific, CLR support might be an approachable project for the community. I recommend the community take it and keep it up to date with pre-releases of Kotlin. With ScalaCLR IIRC, when Typesafe decided to stop supporting it it basically withered as new Scala features were rapidly developed. It also has a better chance than ScalaCLR due to how small the runtime is. But, like Swift with ObjC, since the runtime is so small so many of the libraries are going to targer the JVM and reference JVM libs which may make the cross-VM ecosystem non-existent (doesn't mean it still won't have good CLR uses of course).
- pjmlp 11y ago
  That is my view as well. But having platform specific code hidden behind interfaces is way saner than having to write JNI for almost every framework API when using C++ for business logic. The problem doesn't happen in the other mobile OSes thanks to Objective-C++ and C++/CX. My current approach.
- yole 11y ago
  Right now developing a new backend for Kotlin is much harder than necessary because the compiler doesn't have any IR and any desugaring passes - in other words, each backend has to work directly with the full AST (annotated with types etc., but still using all language constructs). We plan to rework this post-1.0, after which building a new backend will be much more feasible.

platz 11y ago

are non-exhaustive pattern matches in kotlin warnings, errors, or neither? looks like from the docs: "If `when` is used as an expression, the `else` branch is mandatory, unless the compiler can prove that all possible cases are covered with branch conditions." So it is an error, I assume?

kcorbitt 11y ago
With the caveat that I haven't tried it myself: > What about pattern matching? This is where the word “sealed” above comes in handy; we can do an exhaustive pattern match without an else/otherwise branch from https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a#.8dbwaz4yi https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a#.8dbwa...
- commentzorro 11y ago
  This looks to be single value matching only and no compile time exhaustion checks. This looks like really nice (i.e. sugary) alternative to switch but not quite pattern matching.
udalov 11y ago
It's an error only when the 'when'-expression is used as a value, like assigned to a property, passed as an argument or returned from a function. Otherwise it's not an error. There's also a warning for matching enum values over an incomplete set of enum entries, but otherwise non-exhaustive 'when'-expression is green code. You can basically consider 'when'-expressions to be syntax sugar over Java's if-else or ternary operator (?:) chains.
- platz 11y ago
  > non-exhaustive pattern matches So there are no non-exhaustive pattern matches, is what you are saying? i.e. they all must be exhaustive. Except for your enum example
  - udalov 11y ago

eropple 11y ago

I've been using Kotlin for a little while, as the backend language for the side project/maybe-startup I'm working on. I went with it because of my troubling tendency to write Scala code I can't read three weeks later, and in that I think Kotlin's a big success: the Java interop is good (still some weirdness around DI frameworks and non-nullable types, which is unavoidable if you're using something like Jersey with HK2), the language itself has most of the niceties I want, and I find that the tooling is really pretty good in general. And the Kotlin community, in my experience, has been really good (aside from...sigh...yet another Slack chat to be in), unlike the continuing and perpetual disaster of Scala whenever certain members of the This Should Be Haskell mafia are allowed near anyone who's just asking a question. I miss things from Scala once in a while, but they're usually me being way too cute with my code anyway--good for tiny personal things, not for something I'm hoping I'm looking at three years from now, not just three weeks from now.

wpietri 11y ago
That's helpful. I have this side Scala project, a long-lived daemon[1], that I've been meaning to rewrite in something else, as I've grown disenchanted with it. (Bruce Eckel and Paul Phillips contributed to that. [2]) But every alternative I could think of was not so appealing. I'll check this out. [1] https://github.com/wpietri/sunrise https://github.com/wpietri/sunrise [2] https://news.ycombinator.com/item?id=10163446 https://news.ycombinator.com/item?id=10163446

vbezhenar 11y ago

I tried Kotlin in one small project, which used Java API and I can recommend it. There are a lot of handy features there. There were quite a bit of breaking changes, but, of course, it's expected from unreleased language. It wasn't hard to fix things. For me Kotlin is in sweet spot between verbose Java and complex powerful Scala. From a practical point of view, I would prefer it to both. Any competent Java programmer will catch Kotlin fast enough, and it has almost anything I would want from a "improved Java" language.

merb 11y ago

it would be great if playframework also had kotlin support. The problem here is that kotlin has no sbt support.

strictfp 11y ago
Is Play any good these days? Tried it when it was new, was an utter mess. Found a couple of bugs within the first hour or so...
- whateveracct 11y ago
  I know that Play 2 is happily used in production all over the place. I'm guessing it's a lot better than when you used it.
- merb 11y ago
  we still hit a great but since we support legacy printer devices on our applications which using ssl over a custom certificate which changes over every printer. So we would need to have a function that accepts any cerificate inside the ws-client of play. unfortunatly the acceptAllCerts doesn't work in play 2.4+. however we didn't hit more bugs, yet and using it since 2.1

smithkl42 11y ago

Kotlin seems to fill a niche comparable to TypeScript: a language that doesn't try to break new ground, but picks a bunch of tried-and-true ideas to fix severe problems in the underlying platform. Like TypeScript, I hope that it ends up being the right language, with the right compromises, at the right time.

dodyg 11y ago
Yup. It helps that Kotlin is also a smallish language. You can pick it up in a day.

Drup 11y ago

Comparison with Ceylon ?

thom_nic 11y ago
Here's a preso: https://speakerdeck.com/evacchi/kotlin-and-ceylon-modern-programming-languages-for-a-modern-jvm https://speakerdeck.com/evacchi/kotlin-and-ceylon-modern-pro... I can't say I've used Ceylon much but I think Kotlin's syntax is much nicer and it's much easier to approach than Scala.
- mercurial 11y ago
  I'd imagine having Jetbrains behind Kotlin means much better tooling, which is likely to be more important for a lot of people than language features like ADTs.
- evacchi 11y ago
  to be fair, I presented that before Kotlin hit 1.0. A few things that I liked are no more (like the @-less syntax for annotations). But all in all I believe it is still a good commentary.
- deleted 11y ago
  [deleted]

nikolay 11y ago

How is it better than Ceylon 1.2? Ceylon compiles to JVM bytecode, JavaScript, Dart, and will to LLVM in the future. As a language, it's a great superset of Java. I posted [0] about the great new Ceylon 1.2 (which is backed by Red Hat), and nobody seemed to care, but there's so much hype about Kotlin - I don't get it! [0] https://news.ycombinator.com/item?id=10474126 https://news.ycombinator.com/item?id=10474126

clumsysmurf 11y ago
I suspect much of the excitement around Kotlin is coming from Android developers that see the language as their deliverance from Java 6.5.
commentzorro 11y ago
Don't know Ceylon or Kotlin except superficial poking around the websites. So, let me ask you, how is Ceylon better than Kotlin? I'd like to see a good write-up (separate blog post) that compares and contrasts the two. What are use cases where one language would be significantly better than the other? (Edit) Wow! Did not expect such a dearth of samples (for both languages) on Rosetta Code. http://rosettacode.org/wiki/Category:Ceylon http://rosettacode.org/wiki/Category:Ceylon http://rosettacode.org/wiki/Category:Kotlin http://rosettacode.org/wiki/Category:Kotlin and only one overlap: http://rosetta.alhur.es/compare/Ceylon/Kotlin/# http://rosetta.alhur.es/compare/Ceylon/Kotlin/#
- eropple 11y ago
  Given that a strength of Kotlin is that you can dumb-port Java straight to it without even thinking about it, I'm not really surprised it doesn't have much presence on Rosetta Code. It's not the right audience.
pron 11y ago
Not better -- different. In my opinion, it's best to read the two language's design goals to understand the difference (as those matter a lot more than any particular feature). The Kotlin design goals are outlined in the blog post, and the Ceylon design goals can be found here[1]. IMO, a TLDR would be: Ceylon attempts to replace not just the Java language but also the standard libraries, while Kotlin intends to upgrade the language only and blend into the existing ecosystem. That difference explains many if not most of the decisions regarding the particular features of each language. [1]: http://ceylon-lang.org/documentation/1.1/faq/ http://ceylon-lang.org/documentation/1.1/faq/ + http://ceylon-lang.org/blog/2012/01/10/goals/ http://ceylon-lang.org/blog/2012/01/10/goals/

EdwardDiego 11y ago

I'm disappointed with the people who are down-voting this comment, as it's, in my opinion, informative and provides a reasonable summation of the differences between Kotlin and Scala. I'd ask people who disagree to put their disagreement into words.

justthistime_ 11y ago
He has been told by both Scala _AND_ Ceylon language developers that his large walls-of-texts are wrong and are largely made-up stuff which sounds plausible to him. Somehow he feels like he still needs to recycle his nonsense in every thread regardless of how remotely related it is to the topic.
- EdwardDiego 11y ago
  So what, in the above "wall of text", is wrong about Scala or Kotlin? You're not telling what was incorrect, just that the author is _always_ incorrect, which strikes me as hyperbole.
  - deleted 11y ago
    [deleted]
  - justthistime_ 11y ago
    So what, in the above "wall of text", is wrong about Scala or Kotlin? Maybe just check the responses from the last fifteen dozen times? It's not that hard. You're not telling what was incorrect, just that the author is _always_ incorrect, which strikes me as hyperbole. I'm not telling anything. The Scala and Ceylon designers did. They probably know better than me, or him.
    - EdwardDiego 11y ago
      > Maybe just check the responses from the last fifteen dozen times? It's not that hard. So you have no valid criticism of the present statement then? Good to know.

bcbrown 11y ago

How easy is it to write Kotlin code for Hadoop mappers and reducers?

bink-lynch 11y ago

I looked around and found a nice writeup on Kotlin: https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3 https://medium.com/@octskyward/why-kotlin-is-my-next-program...

TorbjornLunde 11y ago

Anybody used it compiled to JavaScript? What’s your experience? How does it compare to TypeScript?