I am probably -0 on the change at this time. I don't see this as a language threat issue but we are very keen to make the barrier to entry as low as possible for new contributors. Over time, I suspect more folks will have picked up some Kotlin exposure, so this wouldn't be as strong as a -1 from me.
Cheers, Paul. On Wed, Mar 20, 2019 at 5:22 PM Cédric Champeau <cchamp...@apache.org> wrote: > Hi folks, > > Some of you have noticed that I have fixed the binary compatibility > reports on master. I also fixed checkstyle and CodeNarc, which were failing > to execute. I did not, however, fixed the many errors we see when running > those, nor the ones with spotbugs. It's a bit annoying because it makes the > "build" task fail, but we can live with that for some time. > > Some of you noticed, because this is the first time I introduce a Gradle > Kotlin DSL script for this. Let me explain why: first, it gives a better > user experience: completion in the IDE is working, and you can navigate to > sources. Second, its syntax is so close to the Groovy one that if I had > replaced .kts with .groovy, I bet hardly anyone would have noticed. > > To me it's a step towards a better build: we should'nt see this as a > threat to Groovy, and I'm not saying that it wouldn't have been possible to > achieve the same thing with Groovy, but this is the reality now: the Kotlin > DSL for Gradle gives a better UX than the Groovy one. I think it' going to > be particularly important for newcomers in the future. And as I am the main > maintainer of the build, it's also important to me, given the little amount > of time I can give to this project. My plan is to migrate the build to > Kotlin, slowly but surely, and as part of this effort, remove a lot of the > bad practices we're using, or internal APIs. Publishing for example is in a > terrible state. > > But coming back to this build script: take a look at it and tell me if > it's not as clear, or even more readable than the Groovy one (you can > compare with the old binarycompatibility.groovy file). Also, I strongly > believe that's an opportunity for us to learn from Kotlin and maybe borrow > some if its features > > So I'm asking you to vote on *keeping* this .kts file, and actually > migrating the build incrementally. If you see Kotlin as a threat, I'd > understand but would be disappointed. > > Thanks, >
