> When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people wr

> When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin. I've never used Kotlin, but this is exactly my experience with Groovy. Ten years ago, my department had some Groovy enthusiasts that pushed it heavily, but now we have a bunch of Groovy systems where the majority of the development staff are NOT Groovy enthusiasts, and many are either new hires or low-cost offshore devs with only Java backgrounds. Now all Groovy provides us is the opportunity to experience new classes of bugs that we probably wouldn't see if they systems were written in Java [1]. Generally, I think long lived systems should be written in some kind of "lowest common denominator" language. That's likely to be more easily maintained long in the future. They especially should NOT be written in some other language where someone can get by by pretending it's the LCD language, since that an invitation for bugs wherever the other language violates LCD language assumptions. [1] My favorite is one where a previous entry-level guy wrote a loop, declared the control variable as a STRING, then used ++ to increment it. Instead of failing fast, Groovy "made sense" of this by interpreting that last char of the string as a char, incrementing that, then coercing the whole thing back to an int for the comparison. This worked, UNTIL the control variable had to go past 9, after which the increment resulted in a ':' and the coercion back to an int started failing in prod.