Nicely written. I totally agree with your assessments.
I'm frustrated almost daily by Kotlin's EXTREMELY awkward constructor logic, and it gets worse when you factor in usage of the init block, which will be required if you actually need to do any work in the constructor. Primary, secondary, init...it's all a bit ridiculous. For the life of me, I cannot fathom what problem the Kotlin devs thought needed to be solved, but I feel confident stating this wasn't the right way to solve it. It feels like someone was showing off: "Look how much logic we can stuff into a single undecipherable line!" Brevity should follow clarity, not the other way around.
Data classes can't participate in inheritance, yet no one can ever infer that restriction. Instead, every Kotlin dev will be forced to discover it once their code fails to compile. Perhaps naming the class FinalSealedDataClass would have been helpful, but allowing inheritance would be better.
And possibly my least favorite language construct of all time (second only to Android's AsyncTask) is this: inline fun<reified T>. Dear lord, I had to google what the word reified even means. It basically means to 'make an abstract thing real', and while technically accurate, is a mightily poor cue for understanding that you're instructing the compiler to translate the generic T into a concrete type at every call site at runtime. And while we're at it, I think Kotlin should reify its own damn T's and inline generic functions as needed without me having to tell it to do so ;-)
And finally, coroutines - designed to make working with threads easier - and all that's required to use them is a complete understanding of absolutely everything about concurrency. Here again, I think the Kotlin devs have conflated simplicity with brevity.
These not-insignificant complaints aside, Kotlin is actually rather fabulous.
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.
Nicely written. I totally agree with your assessments.
I'm frustrated almost daily by Kotlin's EXTREMELY awkward constructor logic, and it gets worse when you factor in usage of the
initblock, which will be required if you actually need to do any work in the constructor. Primary, secondary, init...it's all a bit ridiculous. For the life of me, I cannot fathom what problem the Kotlin devs thought needed to be solved, but I feel confident stating this wasn't the right way to solve it. It feels like someone was showing off: "Look how much logic we can stuff into a single undecipherable line!" Brevity should follow clarity, not the other way around.Data classes can't participate in inheritance, yet no one can ever infer that restriction. Instead, every Kotlin dev will be forced to discover it once their code fails to compile. Perhaps naming the class
FinalSealedDataClasswould have been helpful, but allowing inheritance would be better.And possibly my least favorite language construct of all time (second only to Android's
AsyncTask) is this:inline fun<reified T>. Dear lord, I had to google what the wordreifiedeven means. It basically means to 'make an abstract thing real', and while technically accurate, is a mightily poor cue for understanding that you're instructing the compiler to translate the genericTinto a concrete type at every call site at runtime. And while we're at it, I think Kotlin shouldreifyits own damnT's and inline generic functions as needed without me having to tell it to do so ;-)And finally,
coroutines- designed to make working with threads easier - and all that's required to use them is a complete understanding of absolutely everything about concurrency. Here again, I think the Kotlin devs have conflated simplicity with brevity.These not-insignificant complaints aside, Kotlin is actually rather fabulous.