The kotlin drawbacks are not drawbacks if you want to use the functional programming paradigm. OO doesn't make sense in all domains, so classes and inheritance sometimes add to noise of the program.
Sure, you can do that. But then I would argue that you should go for Haskell or F#, because even if Kotlin has a lot of functional aspects to it, if you really want to go for it, then you might as well go all the way. The merit of Kotlin IMHO is that it supports both paradigms. It just falls short a little on both. For example, on the functional side Kotlin doesn't support Currying or partial application (without additional syntactical tricks). On the OO side, it doesn't support inheritance on data classes.
Kotlin data class is replacement for Python tuple.
I don't think of them as replacements for tuples, and honestly I've never heard th is argument before. They were called data classes by the Kotlin devs for a reason. They can have methods. They basically do everything a regular class does and more, except that they, for some weird reason which I really fail to see, can't use inheritance. Data classes would be a lot more useful if they could inherit at least from one other data class.
In the age of docker container running a JVM makes little sense, it just adds another unnecessary dependency.
I think that this point of view is a little bit on th extreme side. The JVM still gives you a lot of benefits, such as a garbage collector, all the profiling tools (JVisualVM etc.) and in general just a great infrastructure. Languages like Go are catching up, but slowly (different discussion entirely). I would welcome the possibility to compile my kotlin code to a native executable, or even to Go code.
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.
Sure, you can do that. But then I would argue that you should go for Haskell or F#, because even if Kotlin has a lot of functional aspects to it, if you really want to go for it, then you might as well go all the way. The merit of Kotlin IMHO is that it supports both paradigms. It just falls short a little on both. For example, on the functional side Kotlin doesn't support Currying or partial application (without additional syntactical tricks). On the OO side, it doesn't support inheritance on data classes.
I don't think of them as replacements for tuples, and honestly I've never heard th is argument before. They were called data classes by the Kotlin devs for a reason. They can have methods. They basically do everything a regular class does and more, except that they, for some weird reason which I really fail to see, can't use inheritance. Data classes would be a lot more useful if they could inherit at least from one other data class.
I think that this point of view is a little bit on th extreme side. The JVM still gives you a lot of benefits, such as a garbage collector, all the profiling tools (JVisualVM etc.) and in general just a great infrastructure. Languages like Go are catching up, but slowly (different discussion entirely). I would welcome the possibility to compile my kotlin code to a native executable, or even to Go code.