geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <...@apache.org>
Subject Re: Exploring using Kotlin for building the "Cluster Management Service"
Date Sat, 05 Jan 2019 20:00:06 GMT
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 <aanchuri@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
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message