Hacker News new | past | comments | ask | show | jobs | submit login
Kotlin 1.0 Release Candidate (jetbrains.com)
43 points by miralabs on Feb 4, 2016 | hide | past | web | favorite | 5 comments

Too bad that 1.0 will ship without something like Scala Future's. Now you can only have a similar functionality with CompletableStage. It would've been way better to actually have a similar implementation than scala.Future. I mean they wouldn't need Quasar, Akka for basic stuff. However currently you need to stick to Java pendants.

Kotlin has some great things, but overall I still prefer Scala over Kotlin for anything not Android related.

I mean what I would've loved in 1.0:

    - specify Bytecode Level output 6, 7, 8, (9)
    - Futures
    - Macros (Big one especially for SQL Libraries really helpful)
    - Buildsystem supported by Jetbrains. 
    - Support for all major Java Build Systems directly by Jetbrains
However at the moment, kotlin feels like "here we developed a language which we will use internally and we will do the stuff we need, for everything else, do what you please", while most languages do this, the newer ones actually coming with more stuff, ie. rust has a package manager, a build system (it only lacks libraries, where kotlin wouldn't suffer, thanks to java), golang which has also something like a package manager and a build system and a rich library which has great support for "threading".

i mean on kotlin you could use maven or gradle. however maven is like: <dosomething></dosomething> ugliness. and gradle is okai, but it feels wierd sometimes especially since code highlighting in intellij always feels broken.

currently I'm way more looking forward at jetbrains c# project than on kotlin, kotlin needs to evolve and get some libraries for major stuff. (btw. i'm not totally against kotlin, however I thought 1.0 will bring a little bit more to the table, which actually has more than just "faster" compile times than scala, the jvm is rich and there a lot of great languages built on top of it (even python, ruby, js works on it))

Edit Actually this author also has a good point about the good and the bad: http://natpryce.com/articles/000815.html

There's a library that provides Scala-style futures here:

Although given Kotlin's transparent Java interop you can as well use Guava's ListenableFuture which is quite good, or indeed CompletableFuture (which I like less).

WRT build systems: both Maven and Gradle are fully supported in Kotlin, with JetBrains provided plugins and IntelliJ knows how to work with them. So I am not sure why you would want more here. You say there's a highlighting issue, but I never saw such a thing, and wouldn't that be a minor IDE bug rather than a reason to develop a new build/package manager from scratch?

Finally, Kotlin avoids macros (compiler plugins) by choice. The idea is the built-in features let you customise the language enough without full blown AST rewriting.

There is a great build tool for Kotlin called Kobalt. It is quick, simple, and levrages all of the available maven packages.

Other than being MUCH faster to compile than Scala, kotlin is also much easier to read.

Also, Quasar is fantastic.

I'm not really sure I understand your complaints... Kotlin is about encoding the best practices in Java as a language not re-inventing the ecosystem. If you want those other things you should look at something like Ceylon which is actually a fair bit more revolutionary (but at the same time more far more complex).

> Too bad that 1.0 will ship without something like Scala Future's.

I see that as a good thing. Once something is committed to the standard library, it's very hard to get rid of it and the best practices surrounding Futures are still pretty shaky and keep changing from one year to the next.

Better let libraries fight it out and if a practice emerges as really good and long-lasting, then it can be incorporated in the standard library.

Applications are open for YC Summer 2020

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