So to begin, I definitely see some of your points: conciseness sometimes comes with the loss of understandability. Since there is plenty of syntactical sugar in Kotlin, it'll probably happen that one over-engineers parts so that they become hard to follow. On the other hand, conciseness sometimes allows to grasp the overall idea of a code snippet more easily since you don't need all the ceremony.
Some of your arguments sound more like a matter of taste (readability of val/var, chaining, ...). But on extension functions I definitely agree with you, that they could easily create a mess. At least, the suggestion utility of your IDE finds them and gives you the chance to discover whatever your colleague might have already done. And they are definitely an improvement compared to Java's infamous *Utility classes.
I don't get your point about DSLs: a lambda needs curly braces, so your scope is limited. So what has this to do with line wrapping?
About coroutines: it's true that it's still evolving, but at least on JVM they are ready to be used. Frameworks like Ktor are built on them and Ktor claims itself to be ready for enterprise apps.
And last but not least, on nullability: Optional definitely doesn't provide any of the comfortability you have when dealing with Kotlin types. And afaik, it is not planned for Java to introduce the same concept inherent to the language.
So all in all, I would argue Kotlin is definitely ready to replace Java (while not necessary in all places), plus you have this nice multiplatform aspect which enables you to share code between front- and backend.
Agree, sometimes conciseness is convenient. But this type of conciseness is available in Java as well.
It's not about over-engineering, but rather loss of information. There is often a need to refer to declaration to clarify types, for example. This creates constant "go to declaration and back" navigation noise during reading Kotlin code written by other devs. I've observed this noise even with seasoned Kotlin devs.
Extension methods are not replacement to utility methods and Utility classes because they cover only tiny subset of possible use cases. In many cases extensions methods are attached to particular class just because so happened that they have first parameter of this class type.
var/val are not matter of taste, it's a real problem. Any editor (person, not software) or UX expert will point on this pair as a potential source of user mistakes.
Yes, multiple classes are possible, but only one public class is allowed. And, frankly, I never saw any real use case in enterprise apps code.
Under "DSL-ised" I did mean code written with infix functions.
Ktor claims nave nothing to do with everyday enterprise reality. Selection of any technology (even version of technology) in big companies are often based on risk assessment. Immature technologies like coroutines or fibers or Kotlin version 1.40-RC are of high risk and avoided at any cost.
Optional easily can provide perfectly fine level of comfort except without drawbacks of optional chaining (i.e. lack of composability). As an additional benefit, "monadic mindset" (aka "do when/if value available") has much wider application than optional chaining. For example, it allows writing asynchronous code indistinguishable from synchronous.
Taking into account that Kotlin didn't yet provide any sensible advantages over Java for enterprise environment, I see no reasons to wide adoption of Kotlin in this environment.
To make it short: I totally see most of your points, you convinced me that Kotlin has yet a long way to go before being ready for enterprise environments. Hence, only time will show, whether Jetbrains manages to reach their (assumed) goal of replacing Java or not.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ok, this is truely a long answer :D
So to begin, I definitely see some of your points: conciseness sometimes comes with the loss of understandability. Since there is plenty of syntactical sugar in Kotlin, it'll probably happen that one over-engineers parts so that they become hard to follow. On the other hand, conciseness sometimes allows to grasp the overall idea of a code snippet more easily since you don't need all the ceremony.
Some of your arguments sound more like a matter of taste (readability of val/var, chaining, ...). But on extension functions I definitely agree with you, that they could easily create a mess. At least, the suggestion utility of your IDE finds them and gives you the chance to discover whatever your colleague might have already done. And they are definitely an improvement compared to Java's infamous *Utility classes.
Besides from being good style or not, multiple classes per file are also allowed in Java: stackoverflow.com/questions/233669...
I don't get your point about DSLs: a lambda needs curly braces, so your scope is limited. So what has this to do with line wrapping?
About coroutines: it's true that it's still evolving, but at least on JVM they are ready to be used. Frameworks like Ktor are built on them and Ktor claims itself to be ready for enterprise apps.
And last but not least, on nullability:
Optionaldefinitely doesn't provide any of the comfortability you have when dealing with Kotlin types. And afaik, it is not planned for Java to introduce the same concept inherent to the language.So all in all, I would argue Kotlin is definitely ready to replace Java (while not necessary in all places), plus you have this nice multiplatform aspect which enables you to share code between front- and backend.
Agree, sometimes conciseness is convenient. But this type of conciseness is available in Java as well.
It's not about over-engineering, but rather loss of information. There is often a need to refer to declaration to clarify types, for example. This creates constant "go to declaration and back" navigation noise during reading Kotlin code written by other devs. I've observed this noise even with seasoned Kotlin devs.
Extension methods are not replacement to utility methods and Utility classes because they cover only tiny subset of possible use cases. In many cases extensions methods are attached to particular class just because so happened that they have first parameter of this class type.
var/val are not matter of taste, it's a real problem. Any editor (person, not software) or UX expert will point on this pair as a potential source of user mistakes.
Yes, multiple classes are possible, but only one public class is allowed. And, frankly, I never saw any real use case in enterprise apps code.
Under "DSL-ised" I did mean code written with infix functions.
Ktor claims nave nothing to do with everyday enterprise reality. Selection of any technology (even version of technology) in big companies are often based on risk assessment. Immature technologies like coroutines or fibers or Kotlin version 1.40-RC are of high risk and avoided at any cost.
Optional easily can provide perfectly fine level of comfort except without drawbacks of optional chaining (i.e. lack of composability). As an additional benefit, "monadic mindset" (aka "do when/if value available") has much wider application than optional chaining. For example, it allows writing asynchronous code indistinguishable from synchronous.
Taking into account that Kotlin didn't yet provide any sensible advantages over Java for enterprise environment, I see no reasons to wide adoption of Kotlin in this environment.
To make it short: I totally see most of your points, you convinced me that Kotlin has yet a long way to go before being ready for enterprise environments. Hence, only time will show, whether Jetbrains manages to reach their (assumed) goal of replacing Java or not.