5 ms·

Have you ever tried kotlin? I've found it to be an encoding of best practices from Java with nullability pinned down. Really made me enjoy working in a most OO/

Have you ever tried kotlin? I've found it to be an encoding of best practices from Java with nullability pinned down. Really made me enjoy working in a most OO/procedural language again after fleeing to scala for a few years.

bluejekyll 5y ago
Yes. Kotlin is good, but there is a lot of Java out there that needs to be supported. Have you experimented with converting entire projects of Java to Kotlin?
- The_rationalist 5y ago
- halpert 5y ago
  Why would you convert the entire project to Kotlin? It’s trivial to mix the two languages, and in fact most Kotlin applications depend on Java libraries.
  - pjmlp 5y ago
    Jet Brains seems to want ot create an ecosystem of their own, Kotlin still depends on Java is more accurate.
    - halpert 5y ago
      I don’t think that’s true. One of the biggest use cases for Kotlin is Android development. Interop between Kotlin, Java libraries, and the Android SDK is completely seamless.
      - 62951413 5y ago
        It's hard to be certain but we have seen this story in Scala. Among the advantages advertised early was interoperability with Java and access to its huge ecosystem. In practice the Scala ecosystem is completely different (well, Akka is a special case popular in Java projects too). As a trivial example people would rather use ScalaPB instead of officially supported Java library. When I worked on a Kotlin-based system people were adamant to use github.com/JetBrains/Exposed. Which had a couple pages of documentation and was missing features. And then again there's politics. Big/successful companies always end up re-inventing PL wheels. The whole GOOG/ORCL mess gave GOOG incentive to fragment the Java ecosystem too.
        halpert 5y ago
        Ok that’s Scala… Kotlin is already the primary language for all new Android applications. The interop story with Java is unambiguous: Kotlin works well with Java. For instance, Android didn’t rewrite most of their SDK in Kotlin, yet it works just fine. Popular Java libraries like Spring and Dagger work with Kotlin. It really “just works”.
        kaba0 5y ago
        Until the language tears over whether they should support android’s “java 8”, openjdk’s java 17+ with modern features, js, or multiplatform.
        halpert 5y ago
        That’s just random speculation.
- stepbeek 5y ago
  I switched from Scala because I found the interior to be so good. Calling Java from kotlin is easy, and - unlike Scalia - the inverse is also true. I’ve converted several projects from Java to kotlin incrementally and it’s been very smooth.
kaba0 5y ago
Scala 3 has an optional non-null compilation mode which will turn Null into a separate type not subset of every class. In my opinion it is a much more elegant solution than Kotlin’s.
- dtech 5y ago
  It's exactly as elegant for nulls. Kotlin's T? == Scala 3's T | Null. In both Scala 3 and Kotlin, you can't call a method it. Kotlin does have the !! operator for practical purposes like Java interop. Equivalent to this Scala 3 code: extension (t: T) def !!: T = if(t != null) t else throw NullPointerException() I haven't checked after release, how is Scala 3 smart-casting now? E.g. Kotlin and Typescript convert a T? to a T inside an if(t != null) branch, and Scala's left much to be desired when I checked. Scala's and Typescript's union & intersection + smartcasting approach is much more general than Kotlin's T? of course, but Kotlin could introduce that backwards-compatible if they wanted.
  - gavinray 5y ago
    > "I haven't checked after release, how is Scala 3 smart-casting now? E.g. Kotlin and Typescript convert a T? to a T inside an if(t != null) branch, and Scala's left much to be desired when I checked." See: https://docs.scala-lang.org/scala3/reference/other-new-features/explicit-nulls.html#flow-typing https://docs.scala-lang.org/scala3/reference/other-new-featu... It works perfectly well in a number of ways (IE, you can use "=="/"!=" null, use a "match") https://scastie.scala-lang.org/s853XsLoQEKTVosebJHelA https://scastie.scala-lang.org/s853XsLoQEKTVosebJHelA Kotlin is still a better experience when interacting with Java because of inbuilt interop with Java types like "List" though, in my opinion. In Scala you need to use ".asScala", ".asJava" etc.
esarbe 5y ago
I had a look at Kotlin and it's definitively an huge improvement with regards to Java. It is free of all the ceremony and boilerplate of Java and null values are so much less of an issue. Still, coming from Scala I'm a bit underwhelmed. Don't get me wrong - Kotlin is a very fine language with lot of promise and the comparison to Scala is not exactly fair - Scala is just a completely different league. I really like what Odersky and the Scala community did with Scala 3; they lifted the language onto a sound new theoretical framework, streamlined the way implicits are used and got rid of puzzling irregularities. Did I mention the new sound macro system? But I'll stop fawning now. I'm currently working on a project where we use Kotlin instead of Java. Probably wouldn't have taken the job if it was with Java and Kotlin makes it quite fun. But damn - I do miss Scala.
pjmlp 5y ago
I have unfortunately, given the Fellowship of Kotlin at Mountain View dungeons, that even misuses Java features to sell their agenda. I rather use the platform languages without extra tooling and wrapper libraries.
blacklion 5y ago
No JVM language can solve problem of memory layout. I don't care about nullability in my code (to be honest, I don't remember when I seen NullPointerException last time), but I need good performance. At $job we use "arrays of primitives" instead of "array of structs" to have good performance, but such code is very ugly and hard to support. True "primitive" objects which are packed densely in memory and generics over such objects (to use ArrayList or equivalent instead of bare array[]) is main reason what allows .NET code to be faster than JVM code, though .Net compiler (JIT) and VM are much less optimized. But JVM (HotSpot) doesn't have choice now :-( Valhalla, when fully implemented, will gibe a huge and long-awaited performance boost. All these hyped non-nullable Option<> maybe good, but is not a show-stopper. Performance is. Edit: for grammar.
- 62951413 5y ago
  I second that. I don't see NPEs in real life outside of early stage development of a new service. You inject all dependencies in constructors (Preconditions.checkNotNull if you're paranoid enough), make all fields final, and that's about it. I have got very mixed feelings about the extend to which Kotlin goes on null safety for this reason. In traditional/non-FP code bases it's not a problem at all to check for null when a data structure uses it to signify "missing". There are usually not that many places where it's necessary. Getting Java on par with C++/STL would be great though. No need for trove4j/colt. Anything that reduces memory usage without making people think hard would also be great to compete with golang.

bluejekyll 5y ago

Yes. Kotlin is good, but there is a lot of Java out there that needs to be supported. Have you experimented with converting entire projects of Java to Kotlin?

The_rationalist 5y ago
halpert 5y ago
Why would you convert the entire project to Kotlin? It’s trivial to mix the two languages, and in fact most Kotlin applications depend on Java libraries.
- pjmlp 5y ago
  Jet Brains seems to want ot create an ecosystem of their own, Kotlin still depends on Java is more accurate.
  - halpert 5y ago
    I don’t think that’s true. One of the biggest use cases for Kotlin is Android development. Interop between Kotlin, Java libraries, and the Android SDK is completely seamless.
    - 62951413 5y ago
      It's hard to be certain but we have seen this story in Scala. Among the advantages advertised early was interoperability with Java and access to its huge ecosystem. In practice the Scala ecosystem is completely different (well, Akka is a special case popular in Java projects too). As a trivial example people would rather use ScalaPB instead of officially supported Java library. When I worked on a Kotlin-based system people were adamant to use github.com/JetBrains/Exposed. Which had a couple pages of documentation and was missing features. And then again there's politics. Big/successful companies always end up re-inventing PL wheels. The whole GOOG/ORCL mess gave GOOG incentive to fragment the Java ecosystem too.
      - halpert 5y ago
        Ok that’s Scala… Kotlin is already the primary language for all new Android applications. The interop story with Java is unambiguous: Kotlin works well with Java. For instance, Android didn’t rewrite most of their SDK in Kotlin, yet it works just fine. Popular Java libraries like Spring and Dagger work with Kotlin. It really “just works”.
        kaba0 5y ago
        Until the language tears over whether they should support android’s “java 8”, openjdk’s java 17+ with modern features, js, or multiplatform.
        halpert 5y ago
        That’s just random speculation.
stepbeek 5y ago
I switched from Scala because I found the interior to be so good. Calling Java from kotlin is easy, and - unlike Scalia - the inverse is also true. I’ve converted several projects from Java to kotlin incrementally and it’s been very smooth.

kaba0 5y ago

Scala 3 has an optional non-null compilation mode which will turn Null into a separate type not subset of every class. In my opinion it is a much more elegant solution than Kotlin’s.

dtech 5y ago
It's exactly as elegant for nulls. Kotlin's T? == Scala 3's T | Null. In both Scala 3 and Kotlin, you can't call a method it. Kotlin does have the !! operator for practical purposes like Java interop. Equivalent to this Scala 3 code: extension (t: T) def !!: T = if(t != null) t else throw NullPointerException() I haven't checked after release, how is Scala 3 smart-casting now? E.g. Kotlin and Typescript convert a T? to a T inside an if(t != null) branch, and Scala's left much to be desired when I checked. Scala's and Typescript's union & intersection + smartcasting approach is much more general than Kotlin's T? of course, but Kotlin could introduce that backwards-compatible if they wanted.
- gavinray 5y ago
  > "I haven't checked after release, how is Scala 3 smart-casting now? E.g. Kotlin and Typescript convert a T? to a T inside an if(t != null) branch, and Scala's left much to be desired when I checked." See: https://docs.scala-lang.org/scala3/reference/other-new-features/explicit-nulls.html#flow-typing https://docs.scala-lang.org/scala3/reference/other-new-featu... It works perfectly well in a number of ways (IE, you can use "=="/"!=" null, use a "match") https://scastie.scala-lang.org/s853XsLoQEKTVosebJHelA https://scastie.scala-lang.org/s853XsLoQEKTVosebJHelA Kotlin is still a better experience when interacting with Java because of inbuilt interop with Java types like "List" though, in my opinion. In Scala you need to use ".asScala", ".asJava" etc.

esarbe 5y ago

I had a look at Kotlin and it's definitively an huge improvement with regards to Java. It is free of all the ceremony and boilerplate of Java and null values are so much less of an issue. Still, coming from Scala I'm a bit underwhelmed. Don't get me wrong - Kotlin is a very fine language with lot of promise and the comparison to Scala is not exactly fair - Scala is just a completely different league. I really like what Odersky and the Scala community did with Scala 3; they lifted the language onto a sound new theoretical framework, streamlined the way implicits are used and got rid of puzzling irregularities. Did I mention the new sound macro system? But I'll stop fawning now. I'm currently working on a project where we use Kotlin instead of Java. Probably wouldn't have taken the job if it was with Java and Kotlin makes it quite fun. But damn - I do miss Scala.

pjmlp 5y ago

I have unfortunately, given the Fellowship of Kotlin at Mountain View dungeons, that even misuses Java features to sell their agenda. I rather use the platform languages without extra tooling and wrapper libraries.

blacklion 5y ago

No JVM language can solve problem of memory layout. I don't care about nullability in my code (to be honest, I don't remember when I seen NullPointerException last time), but I need good performance. At $job we use "arrays of primitives" instead of "array of structs" to have good performance, but such code is very ugly and hard to support. True "primitive" objects which are packed densely in memory and generics over such objects (to use ArrayList or equivalent instead of bare array[]) is main reason what allows .NET code to be faster than JVM code, though .Net compiler (JIT) and VM are much less optimized. But JVM (HotSpot) doesn't have choice now :-( Valhalla, when fully implemented, will gibe a huge and long-awaited performance boost. All these hyped non-nullable Option<> maybe good, but is not a show-stopper. Performance is. Edit: for grammar.

62951413 5y ago
I second that. I don't see NPEs in real life outside of early stage development of a new service. You inject all dependencies in constructors (Preconditions.checkNotNull if you're paranoid enough), make all fields final, and that's about it. I have got very mixed feelings about the extend to which Kotlin goes on null safety for this reason. In traditional/non-FP code bases it's not a problem at all to check for null when a data structure uses it to signify "missing". There are usually not that many places where it's necessary. Getting Java on par with C++/STL would be great though. No need for trove4j/colt. Anything that reduces memory usage without making people think hard would also be great to compete with golang.