Re: CALCITE-2458 Use of Kotlin for unit tests
Just ran across this thread. I'm not as active on Calcite these days due to
other demands on my time but this thread seems important enough to chime in.
My standard response is -1 to introducing new languages. They are
frequently of the moment (and their features are often adopted by other
languages). They also tend be a barrier to additional adoption and
contribution (although sometimes they engage a new community). They also
risk lack of adoption (for example, in the Arrow project typically only a
small set of contributors work on each language meaning if someone goes on
vacation--or stops contributing--that part of the codebase is virtually
unmaintained for some period of time). However, the biggest issue to me is
that the current contributors are frequently required to maintain other
people's code and thus all of a sudden a bunch of contributors will
probably start to see part of the codebase as less approachable than they
previously did. We already have this problem in Calcite because there is so
much code managed by a very small set of contributors.
Engineers always have good intentions and most people like the idea of
learning a new language. I have no doubt that most of the people on this
list (including myself) would like to learn Kotlin. At the same time,
engineers are also almost always overly optimistic (again, including
myself) and don't really have the time to learn a new language at any
My suggestion might be (at most) to do a trial run with a very constrained
use case that is a tertiary part of the codebase. For example, maybe do it
in one connector (for example the pig connector) and see how that works for
some period of time. If people start to see the benefit there, then maybe
it makes sense to adopt more broadly.
Because of my lack of overall contribution to development on Calcite these
days, I don't want to entirely block this proposal so I'll put my formal
vote on this commit at -0.9. By this I mean I'd be -1 if I was more engaged
but don't think it would be fair to block this from moving forward since
others work way more on the codebase than I do atm.
On Mon, Sep 17, 2018 at 12:21 PM Vladimir Sitnikov <
> I think it time for us to enable use of Kotlin in unit tests.
> There are lots of language features (e.g. name parameters, data classes,
> multiline strings, infix functions, nullability, smart casts, etc) that
> would make code simpler to read and write.
> Note: the change is related to use of Kotlin in test-code only.
> Kotlin use for production classes might require a bit more of thought (e.g.
> the set of dependencies, etc), so let's settle on Kotlin for tests first.
> More details can be found in:
> https://issues.apache.org/jira/browse/CALCITE-2458 (created Aug 8)
> PR: https://github.com/apache/calcite/pull/786 (created Aug 9)
> If no-one objects within a week, I'll assume lazy consensus and commit it.
> It might be nice to gather a bit more feedback on the change though. What
> do you think of the change?
> If you struggle what to say, you might find the below options useful:
> [ ] ++1: 'Wow! I like this! Let's do it!'
> [ ] +1: 'Let's do it!'
> [ ] +0.9: 'This is a cool idea and i like it'