10 ms·

Kotlin: Statically typed programming language targeting the JVM and JS

121 points by tilt 12y ago

iaskwhy 12y ago
I didn't know much about Kotlin but I found out the landing page to be very informative in a pratical way. Nice work, designer(s)!
JustSomeNobody 12y ago
Designing a new language is the new designing a new framework. Ugh.
- laureny 12y ago
  Yeah, screw progress and experimentation, right?
  - JustSomeNobody 12y ago
    If all the languages and frameworks that are being developed were progress, then sure. If they were meant as just experiments, then more power to them. Here's the deal, we'll see a flood of "Why I chose (X) language" posts. A year later we'll see a flood of "Why I left (X) language" posts. Developers read too many blogs and follow too many fads. They are like golfers! "This'll get you an extra 10 yards on your swing!" B.S.
    - skybrian 12y ago
      This is a problem? If not for the early adopters, how would new languages get a chance?
      - peaton 12y ago
        I agree with the positivity. It is always easiest to critique and stick with the familiar. Something we can quantitatively take away from the slur of new languages is that new languages are easier now than ever to create/implement. This should be a good thing. This means faster iteration can occur. Even if that iteration is not necessarily taking place, the creation of new languages verifies this ability.
    - abjorn 12y ago
      So what? I don't know about you, but I started programming for fun. Where's the fun if you never experiment or try new things? You can't discourage people from experimenting with new languages, frameworks, design patterns, etcetera, just because some people might use it and fail.
    - laureny 12y ago
      You're making the dangerous assumption that a failed experiment is synonymous with no progress. We actually learn a lot more from failures than successes.
      - JustSomeNobody 12y ago
        I am not assuming that at all. Re-read my first two sentences. The problem that I see is that developers only want to work on what is new. They don't want to work with C++ because it's old. They don't want to work with Java because it's old. They don't want to work with Ruby because even it is old. It's the same thing with frameworks. There has been an explosion of frameworks because developers can't be caught dead working on something older than 6 months. If one's intention is to rewrite entire applications every year, knock yourself out. But if you're writing apps for customers who expect it to be solid and remain in the field for a useful amount of time, then you need the reliability of C++ or Java or C. Not some language someone whipped together in a handful of weekends. Another commenter mentioned beginning development because it was fun. I did too. It still is, but I also grew to care about the products I develop. And no, it's not fun to chase issues with immature technology when a customer is wanting answers.
  - Pacabel 12y ago
    Has there really been that much actual progress made lately, though? I'd say that C++, Erlang and perhaps Haskell are the most recent languages to bring anything new to the table in a way that's at least somewhat usable in practice. And they're decades old at this point. C++ helped make OO and generic programming feasible. Erlang helped with developing concurrent, distributed, fault-tolerant software. Haskell brought pure functional programming and laziness to a wider audience. Otherwise, the widely-hyped languages of today, including Scala, Ruby, JavaScript, Go, Rust and even Kotlin generally just rehash what C++, Erlang, Haskell and other languages offered several decades ago. Some of those languages, like JavaScript and even Go, are arguably worse in many ways than languages developed in the 1980s or way earlier. At best, we're seeing small, incremental improvements. More realistically, we're just seeing old ideas rehashed again and again, with minor syntactic differences. Thus we aren't really seeing real "experimentation", and we aren't witnessing much "progress".
    - dbaupp 12y ago
      I hate to debate you about Rust; but no other practical language offers same memory-safety with no garbage collection that Rust provides, the lifetime and ownership systems are fairly unique. AIUI, Cyclone had something similar to lifetimes, but in a different manner, and without the considerations for concurrency/data races that Rust has.
    - kasey_junk 12y ago
      This sort of conversation is usually pretty subjective so it will be impossible to actually come to any agreement. That said, ignoring the JVM in this conversation is near criminal. High performance GC, JIT, standardized profiling, etc. are all major steps forward. Are they language improvements? No, but they proved that a VM is a viable target platform and that was under serious debate in the late 90s.
      - Pacabel 12y ago
        I ignored the JVM because it really isn't that special at all, and its supposed benefits haven't been proven to exist in reality. Various types of VMs predated it by decades, including ones that used various forms of GC and JIT compilation. See some of the Pascal and Smalltalk implementations from decades ago as an example of these systems. These did see a fair amount of use, in practice. The JVM isn't particularly portable. It may support most of the major mainstream OSes used today, but it's not like portable C or C++ code (including other language implementations for Perl, Python, and so forth) that can run on all sorts of obscure and ancient systems. Its performance isn't particularly remarkable, either, even with all of the effort that some very large companies have put into it. Its been pretty much relegated to server-side use at this point, and even then we're seeing more and more effort made to move away from it. People are realizing that it's often better to go native, as we're seeing with newer languages like Go and Rust. The JVM did get a lot of hype, and has seen a lot of use, but it's mediocre at best. There's nothing particularly earth-shattering about it.
timclark 12y ago
Is someone bypassing the duplicate submission logic by editing URLs. Earlier submission here - https://news.ycombinator.com/item?id=8036515 https://news.ycombinator.com/item?id=8036515
- coldtea 12y ago
  Well, thanks to that "url editing" we get to know about posts that have gone unoticed before. Or posts that always get lots of new readers interested, despite having been discussed before. If anything, the "duplicate submission logic" is not needed, except if we're talking about real abuse (tons of postings of the same thing that interests noone).
- tilt 12y ago
  Can't actually reach the previous one, still this one is more related to http://blog.jetbrains.com/kotlin/2014/07/a-new-open-source-web-site/ http://blog.jetbrains.com/kotlin/2014/07/a-new-open-source-w...
  - timclark 12y ago
    It works for me, It looks like you've just pasted a ? on the URL.
    - Kiro 12y ago
      A bannable offense in my opinion.
      - deleted 12y ago
        [deleted]
      - bjz_ 12y ago
        I'm cool with somebody re-posting for a site update. I wouldn't have known they'd updated otherwise.
        12y ago
thescrewdriver 12y ago
From the site: Version: 0.8.11
pjmlp 12y ago
With Google's move to InteliJ for Android development, I kind of hoped that they might sponsor Kotlin, but alas Google IO 2014 comes by, and they reaffirm at the Android Team Fireside that only Java and C++ have an welcoming place in Android development. With no official plans for Java 7+ support.
- Benjamin_Dobell 12y ago
  Well, Google have officially dropped Dalvik (i.e. a JVM) in favour of ART (pre-compilation to native code). This is the perfect opportunity to open up the platform to a plethora of new programming languages without needing to worry about being JVM compatible. Instead an LLVM back-end can be produced to compile straight down to ART ABI compatible native code.
  - badlogic 12y ago
    ART is still heavily bound by many JVMisms. All of the framework code is Java as well, so whatever you intend to use with ART has to have some understanding of the Java world as well.
  - mike_hearn 12y ago
    ART is a JVM, it's just not a just-in-time compiling JVM. The JVM is fine for multiple programming languages, as Kotlin nicely proves. And Kotlin targets Java 6 so it should work fine on Android, even though now Android supports Java 7 language features. The missing parts are the Java 7 API's: unfortunately the class library, being based on Apache Harmony (a dead project) does not move forward on Android. However this does not have any effect on Kotlin.
  - pjmlp 12y ago
    ART uses DEX as intermediate format and the framework code is still Java based anyway. Compiling to native code does not change the fact the languages need to be able to interact with ART ABI, which requires Java semantics. This is no different from the old days when OS had multiple system programming languages and C ABI != OS ABI.
fstephany 12y ago
It seems that they don't advertise Android support on the website. Is it dropped? More info here: http://blog.andresteingress.com/2013/12/13/programming-android-with-kotlin/ http://blog.andresteingress.com/2013/12/13/programming-andro... And there: http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin-in-android-studio/ http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin...
- hhariri 12y ago
  Absolutely not! :) In fact under the Features, if you scroll to Versatile card, it's there. We're also working on Android tutorials.
  - fstephany 12y ago
    This is great to hear. Thanks!
- dodyg 12y ago
  It is still there. I just updated my Android project to M8 a few days ago (https://github.com/dodyg/AndroidRivers https://github.com/dodyg/AndroidRivers)
bellerocky 12y ago
How good are Kotlin's async options? It's not like Java threads I hope. I like Kotlin, but a good asynchronous mechanism or real coroutines are really important.
- dodyg 12y ago
  There is no native language async option for now. You use whatever available in the JVM world.
- FreezerburnV 12y ago
  You might want to check out Quasar. (https://github.com/puniverse/quasar https://github.com/puniverse/quasar) While it might not be something built into Kotlin, I would assume that Kotlin's interop with Java would make it easy to use. There's also a library called Pulsar for Clojure that wraps Quasar nicely. (written by the developers who are making Quasar)
- mike_hearn 12y ago
  With lambdas, futures are quite easy to use and compose.
  - MichaelGG 12y ago
    Until you start nesting them and doing exception handling...right?
    - spullara 12y ago
      No, checkout CompletableFuture in Java 8. Nesting and exception handling is pretty great I think.
      - MichaelGG 12y ago
        I looked a quick tutorial - it seems to be just a normal continuation-based approach. If want to have a single try/catch block for a bunch of code that calls many different async tasks among other things, how does that work?
discreteevent 12y ago
Does anyone know how mature js generation and interop is?
martingordon 12y ago
This looks a lot like Swift (or rather, Swift looks a lot like Kotlin).
- dodyg 12y ago
  It would have looked a lot more similar had the earlier planned pattern matching support for Kotlin was implemented.
- mike_hearn 12y ago
  A lot of modern languages look like this now. You could as well say they both look like Scala. But then, Scala also riffs off languages like Haskell in some vague syntaxy way. Swift, I think, is strongly influenced by design trends in modern programming languages. I didn't see a whole that in it that was new though.
  - owlish 12y ago
    From what I see in the clip on the front page, some of the syntax is certainly reminiscent of Groovy as well
    - pjmlp 12y ago
      ML actually
      - mavelikara 12y ago
        I think GP meant (1) the use of "it" as the implicit name of a single argument closure and (2) string interpolation syntax.
    - vorg 12y ago
      I don't see it from the clip... data class Customer(val name: String, val email: String) fun main(args: Array<String>){ val customer = Customer("John Smith", "john.smith@somewhere.com") println(customer) println("Hello Kotlin") } A "data" keyword, "val" and "fun" instead of "def", types postfixed with a colon after the identifier, no "new" keyword for initialization.
dothething 12y ago
Why Kotlin over Groovy? Because it's statically typed? Is this an evolutionary thing, or just preference?
- sadris 12y ago
  umm... massively better performance?
  - olavgg 12y ago
    Groovy isn't slow. My guess is that the performance is quite similar, where Kotlin is faster in some cases and Groovy is faster in some other cases.
    - kasey_junk 12y ago
      Is that remotely true? It's been a long time since I benchmarked it but groovy performance (outside of primitives) was dreadful last time I looked. I'd be pleasantly shocked if it could overcome the dynamic language costs.
      - liquidcool 12y ago
        Not sure when you last looked, but it gets a performance boost from invokedynamic on JDK 1.7 [1] and another from @CompileStatic [2]. Groovy 2.0+ is much better than previous versions. Related, Grails 2.4 adds support for using @CompileStatic in controllers and services, whereas previously you had to keep that in separate classes in src/groovy. 1. http://groovy.codehaus.org/InvokeDynamic+support http://groovy.codehaus.org/InvokeDynamic+support 2. http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+compilation http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+c...
- vorg 12y ago
  Kotlin's for building large software systems using the tightly-integrated IntelliJ plugin, both from Jetbrains. It was built with that use case firmly in mind, and even had contributions from James Strachan (Groovy's creator) and Alex Tkachman (creator of Groovy 2.0's, ummm..., inspiration Groovy++). Groovy's for gluing together Java and JVM apps, testing Java objects, scripting for Grails, 20-line Gradle build scripts, and what not, anything that doesn't scale.
deleted 12y ago
[deleted]
skybrian 12y ago
They say up front that it compiles to JavaScript but there should be more documentation about that. Where are the HTML5 API's? How does JavaScript interoperability work?
- hhariri 12y ago
  What things would you like documented? We're working on providing more tutorials, docs and information. The API docs are being revamped. Old ones have info about DOM/HTML/Browser support: http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/index.html http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/...
  - skybrian 12y ago
    If I want to write a web application and I go to the API reference, it's unclear where to start. It should say whether each library is browser-only, server-only, or works in both places. For example, is kotlin.dom a client or server API? How about kotlin.io? It says that kotlin.io writes to System.out which is a server-side concept, so I'd guess it's server-only? It would also be nice to see examples of how to embed kotlin-based JavaScript in a web page, how to call JavaScript from kotlin, and how to expose a callback function to JavaScript. A good way to help web developers get started might be to port the examples from the React front page to Kotlin.
    - hhariri 12y ago
      Thanks. The API docs are being revamped as I mentioned and those things we hope to solve. We're also working on tutorials for JS. Right now you can see info on JS here: http://hadihariri.com/2013/10/16/writing-kotlin-in-the-browser/ http://hadihariri.com/2013/10/16/writing-kotlin-in-the-brows... which discusses usage, interop and getting started.
munro 12y ago
Looks similar to Haxe, in that they're targeting interoperability. But with less platform support. I personally have yet to use Haxe, but the people I know who use it love it. I'm keeping it in mind for a good use case! Such as sharing application logic across applications, though in practice last time I did that things got very messy, it was easier just to duplicate application logic across applications. Kotlin/Haxe would be great for cross platform libraries though. Both Kotlin and Haxe do have GADT, which is a feature I'm finding harder to live without :D Also Kotlin appears to have record types!
- adrusi 12y ago
  Kotlin seems to be a good deal simpler than Haxe. Haxe seems to be closer to Scala in terms of complexity, while Kotlin really just boils down to a few extra features relative to Java 8. As far as I know, Kotlin does not have algebreic data types. It does have the nullable type `T?` which is basically Option or Maybe, but you can't define your own. Haxe's enums are algebreic types, but I don't think it has full support for generalized algebreic data types.
  - jdonaldson 12y ago
    Haxe has GADTs, and I think they're great. http://en.wikipedia.org/wiki/Haxe#Type_system http://en.wikipedia.org/wiki/Haxe#Type_system
- jdonaldson 12y ago
  Duplicating app logic is not so bad if it's just a simple one off, and you know the languages well. Haxe is pretty awesome once you start working a server/client app from a single code base. You save so much mental energy not having to do context switching on a language, and you're not afraid to make drastic changes to logic or data structures because you're making both changes at the same time.
delecti 12y ago
Am I the only one that really doesn't mind semi-colons? I find it to be a drawback when they aren't required, because it introduces unnecessary ambiguity. If I have to wrap a long line, then there's extra syntax I have to remember to make sure the language realizes that this is all "really" a single line.
- Randgalt 12y ago
  Welcome to the new world of no semicolons and not seeing the type of a thing.
- k__ 12y ago
  Can you elaborate? I write LiveScript and never had a problem with this. I prefer lesser symbols on screen. On the other hand, LS has syntactically significant whitespace which lets you indent wrapped stuff so the compiler sees that it still belongs to the previous command, in many cases.
  - delecti 12y ago
    Specifically in Python, if you're appending lines of text, for example, then you have to add a \ before the newline. Also in Javascript if you omit the semi-colon then sometimes the interpreter gets confused and functionality gets jumbled. Sorry if that's not that specific. I just in general prefer semi-colons being required, because then it fails fast rather than producing subtle bugs later.
minaandrawos 12y ago
It seems interesting but I find myself comparing it to Eclipse's Xtend (http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/ ). Does anyone know if it has an advantage over Xtend?
- antru 12y ago
  Kotlin compiles to bytecode, Xtend transpiles to Java. Depends on situation which is better.
- FractalNerve 12y ago
  minaandrawos's question is really good. I don't know at which situations Xtend would make more sense than Kotlin or vice versa, but I would like to know if it compiles as slow as Scala.
- galaxyLogic 12y ago
  Cool thing about Xtend is that you can actually understand the Java it generates. So once you've used Xtend to generate the Java you can forget about Xtend if you want to. You are not "married" to it. You can later take a Xtend-generated Java-method and start manually modifying it if needed. I just wish Xtend had more support from others besides Eclipse. Also I hope it gets its Ant -support to a better shape, maybe it already is. It is simply a smarter simpler way to write Java. And you don't need to go Java 8 to benefit from "Lambdas".
  - galaxyLogic 12y ago
    Also Xtend chose its name poorly. It's hard too google it without getting advice on how to extend your life etc. SEE: http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/
altschuler 12y ago
A detail I've noticed when compiling to JavaScript is that Kotlin is not a reserved word, and if you bind something to it, it breaks the generated JavaScript. fun main(args : Array<String>) { println("Hello, world!") val Kotlin = 0 } will result in a type error
xiaoma 12y ago
It was really interesting to see Prezi on the list. They hired the creator of Elm and are one of the very few places if not the only place using it in production. If they're using this too they must be a linguistically fearless shop. See this demo and try using the arrow keys to move the turtle: http://elm-lang.org/edit/examples/Intermediate/Turtle.elm http://elm-lang.org/edit/examples/Intermediate/Turtle.elm
- laszlok 12y ago
  http://engineering.prezi.com/blog/2014/01/20/prezi-the-land-of-the-polyglots/ http://engineering.prezi.com/blog/2014/01/20/prezi-the-land-...

121 points by tilt 12y ago

I didn't know much about Kotlin but I found out the landing page to be very informative in a pratical way. Nice work, designer(s)!

JustSomeNobody 12y ago

Designing a new language is the new designing a new framework. Ugh.

laureny 12y ago
Yeah, screw progress and experimentation, right?
- JustSomeNobody 12y ago
  If all the languages and frameworks that are being developed were progress, then sure. If they were meant as just experiments, then more power to them. Here's the deal, we'll see a flood of "Why I chose (X) language" posts. A year later we'll see a flood of "Why I left (X) language" posts. Developers read too many blogs and follow too many fads. They are like golfers! "This'll get you an extra 10 yards on your swing!" B.S.
  - skybrian 12y ago
    This is a problem? If not for the early adopters, how would new languages get a chance?
    - peaton 12y ago
      I agree with the positivity. It is always easiest to critique and stick with the familiar. Something we can quantitatively take away from the slur of new languages is that new languages are easier now than ever to create/implement. This should be a good thing. This means faster iteration can occur. Even if that iteration is not necessarily taking place, the creation of new languages verifies this ability.
  - abjorn 12y ago
    So what? I don't know about you, but I started programming for fun. Where's the fun if you never experiment or try new things? You can't discourage people from experimenting with new languages, frameworks, design patterns, etcetera, just because some people might use it and fail.
  - laureny 12y ago
    You're making the dangerous assumption that a failed experiment is synonymous with no progress. We actually learn a lot more from failures than successes.
    - JustSomeNobody 12y ago
      I am not assuming that at all. Re-read my first two sentences. The problem that I see is that developers only want to work on what is new. They don't want to work with C++ because it's old. They don't want to work with Java because it's old. They don't want to work with Ruby because even it is old. It's the same thing with frameworks. There has been an explosion of frameworks because developers can't be caught dead working on something older than 6 months. If one's intention is to rewrite entire applications every year, knock yourself out. But if you're writing apps for customers who expect it to be solid and remain in the field for a useful amount of time, then you need the reliability of C++ or Java or C. Not some language someone whipped together in a handful of weekends. Another commenter mentioned beginning development because it was fun. I did too. It still is, but I also grew to care about the products I develop. And no, it's not fun to chase issues with immature technology when a customer is wanting answers.
- Pacabel 12y ago
  Has there really been that much actual progress made lately, though? I'd say that C++, Erlang and perhaps Haskell are the most recent languages to bring anything new to the table in a way that's at least somewhat usable in practice. And they're decades old at this point. C++ helped make OO and generic programming feasible. Erlang helped with developing concurrent, distributed, fault-tolerant software. Haskell brought pure functional programming and laziness to a wider audience. Otherwise, the widely-hyped languages of today, including Scala, Ruby, JavaScript, Go, Rust and even Kotlin generally just rehash what C++, Erlang, Haskell and other languages offered several decades ago. Some of those languages, like JavaScript and even Go, are arguably worse in many ways than languages developed in the 1980s or way earlier. At best, we're seeing small, incremental improvements. More realistically, we're just seeing old ideas rehashed again and again, with minor syntactic differences. Thus we aren't really seeing real "experimentation", and we aren't witnessing much "progress".
  - dbaupp 12y ago
    I hate to debate you about Rust; but no other practical language offers same memory-safety with no garbage collection that Rust provides, the lifetime and ownership systems are fairly unique. AIUI, Cyclone had something similar to lifetimes, but in a different manner, and without the considerations for concurrency/data races that Rust has.
  - kasey_junk 12y ago
    This sort of conversation is usually pretty subjective so it will be impossible to actually come to any agreement. That said, ignoring the JVM in this conversation is near criminal. High performance GC, JIT, standardized profiling, etc. are all major steps forward. Are they language improvements? No, but they proved that a VM is a viable target platform and that was under serious debate in the late 90s.
    - Pacabel 12y ago
      I ignored the JVM because it really isn't that special at all, and its supposed benefits haven't been proven to exist in reality. Various types of VMs predated it by decades, including ones that used various forms of GC and JIT compilation. See some of the Pascal and Smalltalk implementations from decades ago as an example of these systems. These did see a fair amount of use, in practice. The JVM isn't particularly portable. It may support most of the major mainstream OSes used today, but it's not like portable C or C++ code (including other language implementations for Perl, Python, and so forth) that can run on all sorts of obscure and ancient systems. Its performance isn't particularly remarkable, either, even with all of the effort that some very large companies have put into it. Its been pretty much relegated to server-side use at this point, and even then we're seeing more and more effort made to move away from it. People are realizing that it's often better to go native, as we're seeing with newer languages like Go and Rust. The JVM did get a lot of hype, and has seen a lot of use, but it's mediocre at best. There's nothing particularly earth-shattering about it.

timclark 12y ago

Is someone bypassing the duplicate submission logic by editing URLs. Earlier submission here - https://news.ycombinator.com/item?id=8036515 https://news.ycombinator.com/item?id=8036515

coldtea 12y ago
Well, thanks to that "url editing" we get to know about posts that have gone unoticed before. Or posts that always get lots of new readers interested, despite having been discussed before. If anything, the "duplicate submission logic" is not needed, except if we're talking about real abuse (tons of postings of the same thing that interests noone).
tilt 12y ago
Can't actually reach the previous one, still this one is more related to http://blog.jetbrains.com/kotlin/2014/07/a-new-open-source-web-site/ http://blog.jetbrains.com/kotlin/2014/07/a-new-open-source-w...
- timclark 12y ago
  It works for me, It looks like you've just pasted a ? on the URL.
  - Kiro 12y ago
    A bannable offense in my opinion.
    - deleted 12y ago
      [deleted]
    - bjz_ 12y ago
      I'm cool with somebody re-posting for a site update. I wouldn't have known they'd updated otherwise.
      - 12y ago

thescrewdriver 12y ago

From the site: Version: 0.8.11

pjmlp 12y ago

With Google's move to InteliJ for Android development, I kind of hoped that they might sponsor Kotlin, but alas Google IO 2014 comes by, and they reaffirm at the Android Team Fireside that only Java and C++ have an welcoming place in Android development. With no official plans for Java 7+ support.

Benjamin_Dobell 12y ago
Well, Google have officially dropped Dalvik (i.e. a JVM) in favour of ART (pre-compilation to native code). This is the perfect opportunity to open up the platform to a plethora of new programming languages without needing to worry about being JVM compatible. Instead an LLVM back-end can be produced to compile straight down to ART ABI compatible native code.
- badlogic 12y ago
  ART is still heavily bound by many JVMisms. All of the framework code is Java as well, so whatever you intend to use with ART has to have some understanding of the Java world as well.
- mike_hearn 12y ago
  ART is a JVM, it's just not a just-in-time compiling JVM. The JVM is fine for multiple programming languages, as Kotlin nicely proves. And Kotlin targets Java 6 so it should work fine on Android, even though now Android supports Java 7 language features. The missing parts are the Java 7 API's: unfortunately the class library, being based on Apache Harmony (a dead project) does not move forward on Android. However this does not have any effect on Kotlin.
- pjmlp 12y ago
  ART uses DEX as intermediate format and the framework code is still Java based anyway. Compiling to native code does not change the fact the languages need to be able to interact with ART ABI, which requires Java semantics. This is no different from the old days when OS had multiple system programming languages and C ABI != OS ABI.

fstephany 12y ago

It seems that they don't advertise Android support on the website. Is it dropped? More info here: http://blog.andresteingress.com/2013/12/13/programming-android-with-kotlin/ http://blog.andresteingress.com/2013/12/13/programming-andro... And there: http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin-in-android-studio/ http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin...

hhariri 12y ago
Absolutely not! :) In fact under the Features, if you scroll to Versatile card, it's there. We're also working on Android tutorials.
- fstephany 12y ago
  This is great to hear. Thanks!
dodyg 12y ago
It is still there. I just updated my Android project to M8 a few days ago (https://github.com/dodyg/AndroidRivers https://github.com/dodyg/AndroidRivers)

bellerocky 12y ago

How good are Kotlin's async options? It's not like Java threads I hope. I like Kotlin, but a good asynchronous mechanism or real coroutines are really important.

dodyg 12y ago
There is no native language async option for now. You use whatever available in the JVM world.
FreezerburnV 12y ago
You might want to check out Quasar. (https://github.com/puniverse/quasar https://github.com/puniverse/quasar) While it might not be something built into Kotlin, I would assume that Kotlin's interop with Java would make it easy to use. There's also a library called Pulsar for Clojure that wraps Quasar nicely. (written by the developers who are making Quasar)
mike_hearn 12y ago
With lambdas, futures are quite easy to use and compose.
- MichaelGG 12y ago
  Until you start nesting them and doing exception handling...right?
  - spullara 12y ago
    No, checkout CompletableFuture in Java 8. Nesting and exception handling is pretty great I think.
    - MichaelGG 12y ago
      I looked a quick tutorial - it seems to be just a normal continuation-based approach. If want to have a single try/catch block for a bunch of code that calls many different async tasks among other things, how does that work?

discreteevent 12y ago

Does anyone know how mature js generation and interop is?

martingordon 12y ago

This looks a lot like Swift (or rather, Swift looks a lot like Kotlin).

dodyg 12y ago
It would have looked a lot more similar had the earlier planned pattern matching support for Kotlin was implemented.
mike_hearn 12y ago
A lot of modern languages look like this now. You could as well say they both look like Scala. But then, Scala also riffs off languages like Haskell in some vague syntaxy way. Swift, I think, is strongly influenced by design trends in modern programming languages. I didn't see a whole that in it that was new though.
- owlish 12y ago
  From what I see in the clip on the front page, some of the syntax is certainly reminiscent of Groovy as well
  - pjmlp 12y ago
    ML actually
    - mavelikara 12y ago
      I think GP meant (1) the use of "it" as the implicit name of a single argument closure and (2) string interpolation syntax.
  - vorg 12y ago
    I don't see it from the clip... data class Customer(val name: String, val email: String) fun main(args: Array<String>){ val customer = Customer("John Smith", "john.smith@somewhere.com") println(customer) println("Hello Kotlin") } A "data" keyword, "val" and "fun" instead of "def", types postfixed with a colon after the identifier, no "new" keyword for initialization.

dothething 12y ago

Why Kotlin over Groovy? Because it's statically typed? Is this an evolutionary thing, or just preference?

sadris 12y ago
umm... massively better performance?
- olavgg 12y ago
  Groovy isn't slow. My guess is that the performance is quite similar, where Kotlin is faster in some cases and Groovy is faster in some other cases.
  - kasey_junk 12y ago
    Is that remotely true? It's been a long time since I benchmarked it but groovy performance (outside of primitives) was dreadful last time I looked. I'd be pleasantly shocked if it could overcome the dynamic language costs.
    - liquidcool 12y ago
      Not sure when you last looked, but it gets a performance boost from invokedynamic on JDK 1.7 [1] and another from @CompileStatic [2]. Groovy 2.0+ is much better than previous versions. Related, Grails 2.4 adds support for using @CompileStatic in controllers and services, whereas previously you had to keep that in separate classes in src/groovy. 1. http://groovy.codehaus.org/InvokeDynamic+support http://groovy.codehaus.org/InvokeDynamic+support 2. http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+compilation http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+c...
vorg 12y ago
Kotlin's for building large software systems using the tightly-integrated IntelliJ plugin, both from Jetbrains. It was built with that use case firmly in mind, and even had contributions from James Strachan (Groovy's creator) and Alex Tkachman (creator of Groovy 2.0's, ummm..., inspiration Groovy++). Groovy's for gluing together Java and JVM apps, testing Java objects, scripting for Grails, 20-line Gradle build scripts, and what not, anything that doesn't scale.

deleted 12y ago

[deleted]

skybrian 12y ago

They say up front that it compiles to JavaScript but there should be more documentation about that. Where are the HTML5 API's? How does JavaScript interoperability work?

hhariri 12y ago
What things would you like documented? We're working on providing more tutorials, docs and information. The API docs are being revamped. Old ones have info about DOM/HTML/Browser support: http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/index.html http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/...
- skybrian 12y ago
  If I want to write a web application and I go to the API reference, it's unclear where to start. It should say whether each library is browser-only, server-only, or works in both places. For example, is kotlin.dom a client or server API? How about kotlin.io? It says that kotlin.io writes to System.out which is a server-side concept, so I'd guess it's server-only? It would also be nice to see examples of how to embed kotlin-based JavaScript in a web page, how to call JavaScript from kotlin, and how to expose a callback function to JavaScript. A good way to help web developers get started might be to port the examples from the React front page to Kotlin.
  - hhariri 12y ago
    Thanks. The API docs are being revamped as I mentioned and those things we hope to solve. We're also working on tutorials for JS. Right now you can see info on JS here: http://hadihariri.com/2013/10/16/writing-kotlin-in-the-browser/ http://hadihariri.com/2013/10/16/writing-kotlin-in-the-brows... which discusses usage, interop and getting started.

munro 12y ago

Looks similar to Haxe, in that they're targeting interoperability. But with less platform support. I personally have yet to use Haxe, but the people I know who use it love it. I'm keeping it in mind for a good use case! Such as sharing application logic across applications, though in practice last time I did that things got very messy, it was easier just to duplicate application logic across applications. Kotlin/Haxe would be great for cross platform libraries though. Both Kotlin and Haxe do have GADT, which is a feature I'm finding harder to live without :D Also Kotlin appears to have record types!

adrusi 12y ago
Kotlin seems to be a good deal simpler than Haxe. Haxe seems to be closer to Scala in terms of complexity, while Kotlin really just boils down to a few extra features relative to Java 8. As far as I know, Kotlin does not have algebreic data types. It does have the nullable type `T?` which is basically Option or Maybe, but you can't define your own. Haxe's enums are algebreic types, but I don't think it has full support for generalized algebreic data types.
- jdonaldson 12y ago
  Haxe has GADTs, and I think they're great. http://en.wikipedia.org/wiki/Haxe#Type_system http://en.wikipedia.org/wiki/Haxe#Type_system
jdonaldson 12y ago
Duplicating app logic is not so bad if it's just a simple one off, and you know the languages well. Haxe is pretty awesome once you start working a server/client app from a single code base. You save so much mental energy not having to do context switching on a language, and you're not afraid to make drastic changes to logic or data structures because you're making both changes at the same time.

delecti 12y ago

Am I the only one that really doesn't mind semi-colons? I find it to be a drawback when they aren't required, because it introduces unnecessary ambiguity. If I have to wrap a long line, then there's extra syntax I have to remember to make sure the language realizes that this is all "really" a single line.

Randgalt 12y ago
Welcome to the new world of no semicolons and not seeing the type of a thing.
k__ 12y ago
Can you elaborate? I write LiveScript and never had a problem with this. I prefer lesser symbols on screen. On the other hand, LS has syntactically significant whitespace which lets you indent wrapped stuff so the compiler sees that it still belongs to the previous command, in many cases.
- delecti 12y ago
  Specifically in Python, if you're appending lines of text, for example, then you have to add a \ before the newline. Also in Javascript if you omit the semi-colon then sometimes the interpreter gets confused and functionality gets jumbled. Sorry if that's not that specific. I just in general prefer semi-colons being required, because then it fails fast rather than producing subtle bugs later.

minaandrawos 12y ago

It seems interesting but I find myself comparing it to Eclipse's Xtend (http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/ ). Does anyone know if it has an advantage over Xtend?

antru 12y ago
Kotlin compiles to bytecode, Xtend transpiles to Java. Depends on situation which is better.
FractalNerve 12y ago
minaandrawos's question is really good. I don't know at which situations Xtend would make more sense than Kotlin or vice versa, but I would like to know if it compiles as slow as Scala.
galaxyLogic 12y ago
Cool thing about Xtend is that you can actually understand the Java it generates. So once you've used Xtend to generate the Java you can forget about Xtend if you want to. You are not "married" to it. You can later take a Xtend-generated Java-method and start manually modifying it if needed. I just wish Xtend had more support from others besides Eclipse. Also I hope it gets its Ant -support to a better shape, maybe it already is. It is simply a smarter simpler way to write Java. And you don't need to go Java 8 to benefit from "Lambdas".
- galaxyLogic 12y ago
  Also Xtend chose its name poorly. It's hard too google it without getting advice on how to extend your life etc. SEE: http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/

altschuler 12y ago

A detail I've noticed when compiling to JavaScript is that Kotlin is not a reserved word, and if you bind something to it, it breaks the generated JavaScript. fun main(args : Array<String>) { println("Hello, world!") val Kotlin = 0 } will result in a type error

xiaoma 12y ago

It was really interesting to see Prezi on the list. They hired the creator of Elm and are one of the very few places if not the only place using it in production. If they're using this too they must be a linguistically fearless shop. See this demo and try using the arrow keys to move the turtle: http://elm-lang.org/edit/examples/Intermediate/Turtle.elm http://elm-lang.org/edit/examples/Intermediate/Turtle.elm

laszlok 12y ago
http://engineering.prezi.com/blog/2014/01/20/prezi-the-land-of-the-polyglots/ http://engineering.prezi.com/blog/2014/01/20/prezi-the-land-...