>It feels to me like a better Java, but still very limited compared to Scala
That sounds very good. Scala overdid it.
That sounds very good. Scala overdid it.
That sounds very good. Scala overdid it.
In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.
- Implicit resolution can be slow, because you can make the compiler do arbitrary work for you. This is completely unrelated to implicit classes themselves.
- Scala had the option to either not ship value types at all, or support only a limited subset of things that can be made work well under the current restrictions. If Scala didn't ship value types, the JVM would have probably never gotten them. You can thank Scala developers later for dragging Java people into the 1990ies.
- Extension methods looks totally cool on paper, but are pretty much useless for writing maintainable, readable code, which also does something useful:
Dev: "Ok, I want to be able to use String as if it
was a collection of chars."
Kotlin: "Sure, just implement all the collection methods
one-by-one."
Dev: "But, but ... all implementations I need are
already implemented in that trait over there?"
Kotlin: "Bad luck, I guess. You could of course just
delegate all your methods to that trait."
Dev: "But then I would need to create a real instance
of that trait first which implements the missing
abstract method ... that's more boilerplate than
just copy-and-pasting the code?"
Kotlin: "Yeah, you have to decide whether to write a
short implementation on your own or pay the
price for sharing common pieces of code."
Dev: "... <much later> ... ok, I now implemented all
all the methods of the collection interface of
my own ... I guess ... the compiler will warn me
if I forgot to implement a method from that
interface or messed up a signature, right?"
Kotlin: "No."
Dev: "I just tried passing my String to a method
expecting a collection ... it doesn't even
compile?"
Kotlin: "Just because you went to all the trouble to make
String act like a collection doesn't mean it's
supported as soon as abstraction enters the
picture."
Dev: "So I can write cute things like myString.map(...)
but as soon as map(...) is moved to a method,
I have to overload that method to accept both
Strings and collections?"
Kotlin: "You could also just write a
StringCollectionWrapper and wrap every String
in that when you need it."
Dev: "I guess the compiler will figure out when I need
to wrap it?"
Kotlin: "No, you have wrap it manually every single time."
Dev: "So extension methods are basically just syntax
for writing static methods in a nicer way?"
Kotlin: "Can you please stop asking questions while I
waste your time?"In Scala, it is an _one_ time effort to make String act "like" collections, while the only solution Kotlin provides means doing the work manually _n_ times: At every call site of the string in question.
Kotlin developers also didn't feel like your point was too convincing: https://github.com/JetBrains/kotlin/blob/master/libraries/st...
At any rate, you never addressed the core point I raised. Saying "implicit resolution isn't related to implicit classes" doesn't seem very convincing. If solving that issue was so easy then why is the use of implicits so frequently identified as a performance issue for tools?
You don't seem to know that Kotlin supports delegation natively. Look up the `by` keyword.
And please just post some code next time you're trying to make a point like this because this dialogue is pretty much impossible to follow.