In our company there are country and/or product te...
# tornadofx
c
In our company there are country and/or product teams. There are some common libraries and modules and then there are product/country-specific ones. My "shoe horning" Kotlin into the codebase started with "our team wants to test out Kotlin, we'll just use it for one of our product specific modules". Then came "we've tested Kotlin in that one module and will now test how it works in all our modules" Then gradle kotlin-dsl became stable and feature complete-ish enough to convert our country specific build scripts to it, then I rewrote our dependencies map to a Kotlin object and moved it to buildSrc, then plugin-like functionality from all build scripts was converted to proper plugins and moved to buildSrc, at the moment, I'm slowly and carefully adding Kotlin to core (shared) projects 🙂 So far no complaints, Kotlin is so easy to read and understand when you already know java and groovy (which is the case for all our devs) that even when people who haven't learned Kotlin yet are doing changes and need to change something minor on Kotlin side, they do it easily.