5 ms·

Too bad records won't have named arguments, this would really have helped for large records. Kotlin is once again ahead both in time as in design.

pron 7y ago
They don't now but they likely will. See "named invocation" here: https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html Kotlin is actually at a disadvantage when it comes to design. It has little to no influence on the Java platform it targets and its ecosystem (or on the Javascript platform and ecosystem it also targets), and so it is forced to shape its designs to fit its environment, while the Java language can shape the ecosystem and platform with its design. You see this pattern in records vs. data classes, coroutines vs. Loom, and inline types in both languages. Kotlin's solutions are always more complex and less harmonious in their environment; they need more knobs and joints so that they could fit the contours of the existing constructs around it, on which they have no power. Don't get me wrong, it's doing fine with the cards it's got, but it's clear that it does not have the freedoms of a "platform language."
- deleted 7y ago
  [deleted]
- MrBuddyCasino 7y ago
  > They don't now but they likely will. See "named invocation" here: https://cr.openjdk.java.net/~briangoetz/a https://cr.openjdk.java.net/~briangoetz/a This is good news! > It has little to no influence on the Java platform it targets and its ecosystem It certainly influenced the ecosystem by showing what is possible, and making the shortcomings of Java even more obvious. It has replaced Java (and to some degree, Scala) as the default backend language at some shops, because of less boilerplate and null-safety, leading to better and more maintainable code. Its running the apps on worlds biggest smartphone OS. It may not have pull over the JVM‘s direction, but afaik that had not been a problem so far. Kotlin‘s performance is on-par with Java.
  - pron 7y ago
    > It certainly influenced the ecosystem by showing what is possible Not really. The new features are much similar to their ML (and Scala) counterparts, and ML was well-known to Java's original designers. It is simply a matter of priorities and familiarity. It is true that Kotlin made some ideas more familiar to the point that Java was able to adopt them, and that is why Java benefits from Kotlin existing as an option on the Java platform. The Java language tries not to adopt a feature until it has been tried for a long-enough time by a large-enough number of developers. > It has replaced Java (and to some degree, Scala) as the default backend language at some shops Yes, but to put it in perspective, its penetration on the Java platform is around 2-5%, not higher than Scala's penetration ten years ago. > leading to better and more maintainable code. That is a hypothesis that some believe but does not seem to have any actual empirical support. > Kotlin‘s performance is on-par with Java. Yes, and that is a big problem for Kotlin. Kotlin was created at a time of stagnation for Java -- Sun's last years and the first years at Oracle -- and when Android was still similar to Java. Those two platforms have now diverged greatly, and will diverge even more, and it will be impossible to have a language that is at once the same on those different platforms and aims not to introduce performance overheads. Kotlin will either split into two languages (like Java and Android's "Java"), focus on one platform, or introduce performance overheads.
pjmlp 7y ago
Kotlin can only play catch up with platform features. In worst case it will end up with duplicated language features, because it won't be able to merge its original design with what the platform is capable of. Type annotations in SAM types, loom vs co-routines, streams vs sequences, inline types are already a couple of examples. Then since JetBrains wants to make Kotlin into a platform of its own, the language has to marry JVM, JS, Native and Android semantics, which in time will only get worse to keep writing multiplaform code. In worst case, a library author will need to write one full implementation per platform, with the common denominator for parameters and return types.
- MrBuddyCasino 7y ago
  > In worst case it will end up with duplicated language features, because it won't be able to merge its original design with what the platform is capable of. Kotlin is a different language, it is not supposed to be "Java + X". It decided to do things differently even when it could have decided to 100% match Java. So I don't quite get that argument? Unless it results in interop or performance issues, which I haven't witnessed as of yet.

pron 7y ago

They don't now but they likely will. See "named invocation" here: https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html Kotlin is actually at a disadvantage when it comes to design. It has little to no influence on the Java platform it targets and its ecosystem (or on the Javascript platform and ecosystem it also targets), and so it is forced to shape its designs to fit its environment, while the Java language can shape the ecosystem and platform with its design. You see this pattern in records vs. data classes, coroutines vs. Loom, and inline types in both languages. Kotlin's solutions are always more complex and less harmonious in their environment; they need more knobs and joints so that they could fit the contours of the existing constructs around it, on which they have no power. Don't get me wrong, it's doing fine with the cards it's got, but it's clear that it does not have the freedoms of a "platform language."

deleted 7y ago
[deleted]
MrBuddyCasino 7y ago
> They don't now but they likely will. See "named invocation" here: https://cr.openjdk.java.net/~briangoetz/a https://cr.openjdk.java.net/~briangoetz/a This is good news! > It has little to no influence on the Java platform it targets and its ecosystem It certainly influenced the ecosystem by showing what is possible, and making the shortcomings of Java even more obvious. It has replaced Java (and to some degree, Scala) as the default backend language at some shops, because of less boilerplate and null-safety, leading to better and more maintainable code. Its running the apps on worlds biggest smartphone OS. It may not have pull over the JVM‘s direction, but afaik that had not been a problem so far. Kotlin‘s performance is on-par with Java.
- pron 7y ago
  > It certainly influenced the ecosystem by showing what is possible Not really. The new features are much similar to their ML (and Scala) counterparts, and ML was well-known to Java's original designers. It is simply a matter of priorities and familiarity. It is true that Kotlin made some ideas more familiar to the point that Java was able to adopt them, and that is why Java benefits from Kotlin existing as an option on the Java platform. The Java language tries not to adopt a feature until it has been tried for a long-enough time by a large-enough number of developers. > It has replaced Java (and to some degree, Scala) as the default backend language at some shops Yes, but to put it in perspective, its penetration on the Java platform is around 2-5%, not higher than Scala's penetration ten years ago. > leading to better and more maintainable code. That is a hypothesis that some believe but does not seem to have any actual empirical support. > Kotlin‘s performance is on-par with Java. Yes, and that is a big problem for Kotlin. Kotlin was created at a time of stagnation for Java -- Sun's last years and the first years at Oracle -- and when Android was still similar to Java. Those two platforms have now diverged greatly, and will diverge even more, and it will be impossible to have a language that is at once the same on those different platforms and aims not to introduce performance overheads. Kotlin will either split into two languages (like Java and Android's "Java"), focus on one platform, or introduce performance overheads.

pjmlp 7y ago

Kotlin can only play catch up with platform features. In worst case it will end up with duplicated language features, because it won't be able to merge its original design with what the platform is capable of. Type annotations in SAM types, loom vs co-routines, streams vs sequences, inline types are already a couple of examples. Then since JetBrains wants to make Kotlin into a platform of its own, the language has to marry JVM, JS, Native and Android semantics, which in time will only get worse to keep writing multiplaform code. In worst case, a library author will need to write one full implementation per platform, with the common denominator for parameters and return types.

MrBuddyCasino 7y ago
> In worst case it will end up with duplicated language features, because it won't be able to merge its original design with what the platform is capable of. Kotlin is a different language, it is not supposed to be "Java + X". It decided to do things differently even when it could have decided to 100% match Java. So I don't quite get that argument? Unless it results in interop or performance issues, which I haven't witnessed as of yet.