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 depth. 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 < sitnikov.vladi...@gmail.com> wrote: > Hi, > > 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' > > Vladimir >
