6 ms·

In terms of why we'd want to, there is this note here: https://kotlinlang.org/docs/reference/comparison-to-java.html https://kotlinlang.org/docs/reference/compa

by shubb 9y ago

In terms of why we'd want to, there is this note here: https://kotlinlang.org/docs/reference/comparison-to-java.html https://kotlinlang.org/docs/reference/comparison-to-java.htm... Other factors to consider are tools support, how often interoprability with java libraries causes problems. Would be nice to hear from someone who has used it a bit about what the state of these is?

betatest 9y ago
Come on. This is not about actual production stuff. It's new! It's cool! That's pretty much it.
- dcow 9y ago
  No so. Many people use it in production. The language has been around for 7 years and a stable 1.0+ release for over a year. It's very much more mature than swift and rust and certainly sibling to go in that regard.
  - jorgemf 9y ago
    I tried to explain exactly this before and a lot of people didn't get it. 1.0 doesn't mean anything, JetBrains spent so much time to make something stable and good. That is why kotlin didn't suffer of the big changes swift suffered since its 1.0. (because kotlin suffered those changes before 1.0)
  - EugeneOZ 9y ago
    not trying to say against Kotlin, but Rust has 2 years after 1.0 :)
on_and_off 9y ago
I can talk about this in the context of Android. First I should point out that many large Android apps are using Kotlin. There is a lot of momentum behind Kotlin on Android, that's why Google adopted it. Tools support is really good. Jetbrains knows how to create tools and it shows. Using kotlin also shows you how great the android plugin for java is. Nothing major, but little features like shortcuts to create a string/drawable resource are sometimes missing in kotlin. Jetbrains is missing that gap though, and we should quickly reach parity now that the language is officially supported. Interop with Java is equally great ! Both java & kotlin output bytecode, so they can dialog easily. Some interop caveats : - sometimes calling java from kotlin is not idiomatic. However nowadays many libs are already offering kotlin bindings and again, this should improve. - similarly, calling kotlin from java can be a bit awkward syntactically speaking. - kotlin guarantees nullability behavior, but this can be broken at the interface with java in a couple of cases. If the java code lack @nonnull @nullable annotations, it is up to you to handle their nullability. Similarly, kotlin classes instantiated from java code can mess with nullability. If you data class contains a nonnull property and you instantiate this class with Moshi (a json parser), if the corresponding json field is missing you end up with a null field on a nonnull property. So it is pretty rare, but you can still end up with some NPE.
kodablah 9y ago
I am a pretty big fan, but for non-Android contexts I still like Scala better for a ton of reasons. I wrote a large Kotlin lib[0] the other day and documented a few annoyances[1] I had with it and the devs were very responsive (though non-devs seemed to pick apart maybe one or two of bullet points to dismiss the entire critique). In the future I would use Kotlin for any Android need (obviously) and any time where I wanted to be lighter weight than Scala. As for native/JS use, I am waiting on the multiplatform story to materialize more before I have a strong opinion, but I would still go with Scala for how easy it is to develop multiplatform libs/progs w/ JVM/native/JS where I can easily have platform specific pieces. Kotlin is almost there[2], but not quite yet. 0 - https://github.com/cretz/asmble https://github.com/cretz/asmble 1 - https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db116c https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db11... 2 - https://discuss.kotlinlang.org/t/abstraction-w-jvm-and-js-impls/2355 https://discuss.kotlinlang.org/t/abstraction-w-jvm-and-js-im...
mintplant 9y ago
To me the most promising aspect seems to be async-await on Android. It'd eliminate so much frustration in developing for that platform. In general, after bouncing between various desktop, mobile, and web-based technologies, I've come to the conclusion that any binding/event-based GUI system needs some sort of async-await or futures support to be truly workable. Otherwise, performing background tasks without locking up the UI involves way too much boilerplate and tends to blow up the architectural complexity of the application.
- stevenwoo 9y ago
  What do you think of EventBus on Android versus what you ended up using? https://github.com/greenrobot/EventBus https://github.com/greenrobot/EventBus Just looking to learn new things.
vbezhenar 9y ago
I've used Kotlin a bit. I can't say anything bad, things just work. That said, idiomatic Kotlin differs from idiomatic Java, so some wrappers are nice to have. And it's really sad, that Jetbrains ditched idea to automatically infer nullability from bytecode, I hope, they'll revisit this decision in the future.

by shubb 9y ago

betatest 9y ago

Come on. This is not about actual production stuff. It's new! It's cool! That's pretty much it.

dcow 9y ago
No so. Many people use it in production. The language has been around for 7 years and a stable 1.0+ release for over a year. It's very much more mature than swift and rust and certainly sibling to go in that regard.
- jorgemf 9y ago
  I tried to explain exactly this before and a lot of people didn't get it. 1.0 doesn't mean anything, JetBrains spent so much time to make something stable and good. That is why kotlin didn't suffer of the big changes swift suffered since its 1.0. (because kotlin suffered those changes before 1.0)
- EugeneOZ 9y ago
  not trying to say against Kotlin, but Rust has 2 years after 1.0 :)

on_and_off 9y ago

I can talk about this in the context of Android. First I should point out that many large Android apps are using Kotlin. There is a lot of momentum behind Kotlin on Android, that's why Google adopted it. Tools support is really good. Jetbrains knows how to create tools and it shows. Using kotlin also shows you how great the android plugin for java is. Nothing major, but little features like shortcuts to create a string/drawable resource are sometimes missing in kotlin. Jetbrains is missing that gap though, and we should quickly reach parity now that the language is officially supported. Interop with Java is equally great ! Both java & kotlin output bytecode, so they can dialog easily. Some interop caveats : - sometimes calling java from kotlin is not idiomatic. However nowadays many libs are already offering kotlin bindings and again, this should improve. - similarly, calling kotlin from java can be a bit awkward syntactically speaking. - kotlin guarantees nullability behavior, but this can be broken at the interface with java in a couple of cases. If the java code lack @nonnull @nullable annotations, it is up to you to handle their nullability. Similarly, kotlin classes instantiated from java code can mess with nullability. If you data class contains a nonnull property and you instantiate this class with Moshi (a json parser), if the corresponding json field is missing you end up with a null field on a nonnull property. So it is pretty rare, but you can still end up with some NPE.

kodablah 9y ago

I am a pretty big fan, but for non-Android contexts I still like Scala better for a ton of reasons. I wrote a large Kotlin lib[0] the other day and documented a few annoyances[1] I had with it and the devs were very responsive (though non-devs seemed to pick apart maybe one or two of bullet points to dismiss the entire critique). In the future I would use Kotlin for any Android need (obviously) and any time where I wanted to be lighter weight than Scala. As for native/JS use, I am waiting on the multiplatform story to materialize more before I have a strong opinion, but I would still go with Scala for how easy it is to develop multiplatform libs/progs w/ JVM/native/JS where I can easily have platform specific pieces. Kotlin is almost there[2], but not quite yet. 0 - https://github.com/cretz/asmble https://github.com/cretz/asmble 1 - https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db116c https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db11... 2 - https://discuss.kotlinlang.org/t/abstraction-w-jvm-and-js-impls/2355 https://discuss.kotlinlang.org/t/abstraction-w-jvm-and-js-im...

mintplant 9y ago

To me the most promising aspect seems to be async-await on Android. It'd eliminate so much frustration in developing for that platform. In general, after bouncing between various desktop, mobile, and web-based technologies, I've come to the conclusion that any binding/event-based GUI system needs some sort of async-await or futures support to be truly workable. Otherwise, performing background tasks without locking up the UI involves way too much boilerplate and tends to blow up the architectural complexity of the application.

stevenwoo 9y ago
What do you think of EventBus on Android versus what you ended up using? https://github.com/greenrobot/EventBus https://github.com/greenrobot/EventBus Just looking to learn new things.

vbezhenar 9y ago

I've used Kotlin a bit. I can't say anything bad, things just work. That said, idiomatic Kotlin differs from idiomatic Java, so some wrappers are nice to have. And it's really sad, that Jetbrains ditched idea to automatically infer nullability from bytecode, I hope, they'll revisit this decision in the future.