4 ms·

From what I have seen, I'd probably pick Kotlin if I had to be on the JVM. Seems to strike a nice balance between sanding off the rough edges of Java syntax, a

From what I have seen, I'd probably pick Kotlin if I had to be on the JVM. Seems to strike a nice balance between sanding off the rough edges of Java syntax, and still being conventional and blub enough that it won't put people off.

dboreham 6y ago
Are you assigning any cost to : Kotlin is not Java and therefore new tools, developer training, etc are required? I'd want Kotlin to be significantly better than Java to justify the fact that it's not Java, if you see what I mean.
- dep_b 6y ago
  You can write Java in Kotlin in less than a day.
xwolfi 6y ago
Not sure everyone agrees but each time I've used type inference language (really just Groovy to be honest, but many many many different teams and companies), it ended up with an enormous mess of code that the brain of all of us devs had to parse themselves. We rolled back to Java many such critical paths just to be able to maintain them. My little pitch when starting a migration project in a distressed no-type language team is to make them read the code and explain it, while asking about the type of objects they use and show them when they read it's their brain parsing it with high effort. If they de-optimize and just write the types more often, it becomes much clearer longer. You can type usually in those language but often people want to use the "proper way" as shown in ultra simplistic examples in manuals for sales pitches and end up thinking the right way to code is to write as little as possible (combined with the no-comment belief they have but don't map to "no comment because clear enough code").
- thrower123 6y ago
  I mean, Groovy is terrible, and there is not very good tooling for it. That's not the case for Kotlin, that has the full weight of JetBrains behind it.
- zmmmmm 6y ago
  > We rolled back to Java many such critical paths just to be able to maintain them I guess that's what I see as one of the advantages of Groovy. You can do ultra rapid implementation of something with minimal code and then as it becomes more critical you increase its type safety by adding first Groovy type hints, but further along that curve, convert it fully to Java or another statically typed language. So what you describe as a problem I see as sort of, optimal workflow, and the real problem is being forced to universally choose one or the other in other languages.

dboreham 6y ago

Are you assigning any cost to : Kotlin is not Java and therefore new tools, developer training, etc are required? I'd want Kotlin to be significantly better than Java to justify the fact that it's not Java, if you see what I mean.

dep_b 6y ago
You can write Java in Kotlin in less than a day.

xwolfi 6y ago

Not sure everyone agrees but each time I've used type inference language (really just Groovy to be honest, but many many many different teams and companies), it ended up with an enormous mess of code that the brain of all of us devs had to parse themselves. We rolled back to Java many such critical paths just to be able to maintain them. My little pitch when starting a migration project in a distressed no-type language team is to make them read the code and explain it, while asking about the type of objects they use and show them when they read it's their brain parsing it with high effort. If they de-optimize and just write the types more often, it becomes much clearer longer. You can type usually in those language but often people want to use the "proper way" as shown in ultra simplistic examples in manuals for sales pitches and end up thinking the right way to code is to write as little as possible (combined with the no-comment belief they have but don't map to "no comment because clear enough code").

thrower123 6y ago
I mean, Groovy is terrible, and there is not very good tooling for it. That's not the case for Kotlin, that has the full weight of JetBrains behind it.
zmmmmm 6y ago
> We rolled back to Java many such critical paths just to be able to maintain them I guess that's what I see as one of the advantages of Groovy. You can do ultra rapid implementation of something with minimal code and then as it becomes more critical you increase its type safety by adding first Groovy type hints, but further along that curve, convert it fully to Java or another statically typed language. So what you describe as a problem I see as sort of, optimal workflow, and the real problem is being forced to universally choose one or the other in other languages.