Hi there Aditya,
Thank you for raising this topic. I've been thinking of using Kotlin for
a VERY long time now.
I believe that Kotlin will provide is with many benefits other than just
`non-nullable` fields/parameters but also with immutability.
Conciseness of code is another benefit and the VERY strong functional
and much improved lambda support.
Imo, Kotlin is easy to pick up and learn and just as easy to read for a
non-Kotlin developer. It is definitely an huge step up from Scala from a
simplicity and "just pick up and code".
To address some of the points that were raised:
* /When is it appropriate to use Kotlin/? - There is no definitive
answer to this one... Always, never, only when you want to.. The
interop with Java is second to none and having Kotlin function
interweaved with Java code is simple and easy to do.
* /Are there sufficient number of commiters with Kotlin experience to
maintain the work/? - Kotlin has a strong growth in adoption. It all
started with Android and JS, but it has definitely gained more
traction in traditional Java applications as well. Imo, Kotlin is
easy to read, easy to learn and definitely easy to maintain, not
like Scala that requires some effort to learn and maintain.
* /How will the introduction of Kotlin affect development exp and
build times/? - There is little overhead to compile Kotlin code, add
a few milliseconds here and there. As for development exp, from all
developers I've interacted with, they've found Kotlin easy to deal
with. I don't believe this would be a problem, unless you are averse
to change and learning...
* /Does this increase the learning curve for new committers/? - I
don't believe this to be an issue. Given that we won't be
exclusively switching over to Kotlin and would still support Java.
Would it have an impact for committers to maintain existing Kotlin
code, possibly yes. If you've never written Kotlin code before, it
would be a learning moment, but not so steep that it cannot be
mastered. In addition, any code that is committed will be reviewed
and in true agile fashion, the code would be reviewed, commented on
and possibly have some pointers on how to do things better, so it's
a learning moment.
I believe that Kotlin can have a much larger impact. Kotlin Coroutines
<https://kotlinlang.org/docs/reference/coroutines-overview.html>, which
will help with writing async, concurrent code, without really have to
know and understand Java threading extensively.
Ktor <https://ktor.io/>, a simplified async communications framework
RSocket-Kotlin <https://github.com/rsocket/rsocket-kotlin>, a reactive
communication framework
Of course Spring provides Kotlin support. Kofu
<https://github.com/spring-projects/spring-fu/blob/master/kofu/README.adoc>,
a simplified Kotlin DSL based configuration tool for SpringBoot, of
course there is a Java equivalent Jofu
<https://github.com/spring-projects/spring-fu/blob/master/jafu/README.adoc>.
Kotlin.link <https://kotlin.link/>, is collection of resources spanning
everything from learning, libraries, frameworks, etc... all for Kotlin
The final step of course would be Kotlin Native
<https://kotlinlang.org/docs/reference/native-overview.html>, which
allows the compilation of "pure" Kotlin code onto many different
platform using the LLVM <https://llvm.org/>. Thereby providing the
ability to eventually have an application that can be compiled into
native binaries for many different platforms, as described HERE
<https://kotlinlang.org/docs/reference/native-overview.html>.
So, in my mind, the question that needs to be answered, can we afford
not to use Kotlin.
--Udo
On 1/3/19 16:16, Aditya Anchuri wrote:
Bringing the discussion on the PR back to the dev list
An important point that was raised by Anthony was: "
Introducing a new language to the Geode project raises some questions that
we need to answer as a community before adopting this proposal:
- When is it appropriate to use Kotlin? When should we prefer Java?
- Are there a sufficient number of committers with Kotlin experience to
maintain the work over the long-term?
- How will the introduction of Kotlin affect the development experience
and build times?
- Does this increase the learning curve for new committers?
I think I would be more comfortable exploring this change in a submodule
rather than in geode-core. I would also like to see all the REST code move
to geode-web or geode-mgmtso that we can finally fix those broken
dependencies. Specifically we should aim to delete thewebJar` Gradle task
from geode-core."
I feel that some of these questions can be answered better by actually
introducing Kotlin into the codebase and seeing the results -- but
obviously there is a concern with how locked-in we get if we come to the
conclusion that Kotlin is not for us. We will look into introducing as a
submodule that is a sibling to geode-core, and revisit things. Closing the
PR for now, I feel I have the feedback I need.
-Aditya
On Wed, Jan 2, 2019 at 3:11 PM Aditya Anchuri <aanch...@pivotal.io> wrote:
Hi everyone,
As part of work on the proposed Cluster Management API (
https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_GEODE_Cluster-2BManagement-2BService&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=eizM8j4ZzXpU2_4tKNPdsrNNjryTeKuT6UdYhvucPpY&m=9UReCr36HOoKmKBA2EeR4Yt90PYE6_Gc8UYqixePiH0&s=kkajY3s5AEv0xT1NsfOvrKeU3TrwBNvnywM4MvSCRNI&e=),
some of us have been exploring introducing Kotlin into the codebase. One of
the things I personally love about Kotlin is null references being
controlled by the type system, reducing the incidence of null pointer
errors.
Other pros can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__kotlinlang.org_docs_reference_comparison-2Dto-2Djava.html&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=eizM8j4ZzXpU2_4tKNPdsrNNjryTeKuT6UdYhvucPpY&m=9UReCr36HOoKmKBA2EeR4Yt90PYE6_Gc8UYqixePiH0&s=O6ZPArxbBsO7-WfW8hLm_lKRsN-fbhYcrev89eBV-gg&e=
We have made a very basic PR as to how this could potentially work.
Personally, I see this usecase as less of a chance to shine for Kotlin than
other potential usecases within geode, because of the fact that we'd still
end up using a lot of Java objects from geode-core in order to exercise the
"create region" functionality. However, I could make a case for Kotlin just
from the fact that it is a more modern language.
Would love to get people's feedback on what they think about introducing
Kotlin to the geode codebase, and whether it makes sense for the Cluster
Management API.
https://github.com/apache/geode/pull/3049
Thanks,
-Aditya
