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://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service), > 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://kotlinlang.org/docs/reference/comparison-to-java.html > > 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 > >
