5 ms·

Note that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good ind

Note that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good indicator of long-term sustainability.

moron4hire 7y ago
Yeah, it's not like it's a Google project. You can probably expect JetBrains to support Kotlin going long into the future.
pjmlp 7y ago
Nowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.
- thu2111 7y ago
  Panama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin. As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.
  - pjmlp 7y ago
    Kotlin inline classes are heap allocated, they are just syntax sugar for regular classes. One cannot just change their semantics after the fact.
    - Nullabillity 7y ago
      Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for static methods. The object itself is erased completely whenever possible (just like primitive values).
      - pjmlp 7y ago
        Which is not the same as the semantic meaning of doing stack allocations or being stored in registers.
        Nullabillity 7y ago
        The following: case class Foo(x: Int) extends AnyVal { def square: Int = x * x } val bar: Foo = Foo(5) println(bar.square) // => 25 Compiles down to (the moral equivalent of) object Foo { def square(x: Int): Int = x * x } val bar: Int = 5 println(Foo.square(bar)) // => 25 If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory).
        pjmlp 7y ago
        Neither of those represent the same semantics of: inline class { ... ] Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.
        Nullabillity 7y ago
        You're correct that the Scala version isn't ABI-compatible. But Scala doesn't care about ABI between minor releases anyway, so that probably wouldn't stop them from changing it to align with Java. There is also precedence for this, Scala 2.12 changed the encoding of lambdas from anonymous classes to Java 8's invokedynamic.
bitL 7y ago
SUN was supposed to be here forever as well...
zmmmmm 7y ago
That cuts both ways though. If JetBrains goes away or something shifts their corporate interest away from that then Kotlin has zero support at all. Whereas other languages are built on grass roots foundations. It's certainly unlikely in the short term but it's hard to say long term about the future of any company.

Note that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good indicator of long-term sustainability.

moron4hire 7y ago

Yeah, it's not like it's a Google project. You can probably expect JetBrains to support Kotlin going long into the future.

pjmlp 7y ago

Nowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.

thu2111 7y ago
Panama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin. As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.
- pjmlp 7y ago
  Kotlin inline classes are heap allocated, they are just syntax sugar for regular classes. One cannot just change their semantics after the fact.
  - Nullabillity 7y ago
    Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for static methods. The object itself is erased completely whenever possible (just like primitive values).
    - pjmlp 7y ago
      Which is not the same as the semantic meaning of doing stack allocations or being stored in registers.
      - Nullabillity 7y ago
        The following: case class Foo(x: Int) extends AnyVal { def square: Int = x * x } val bar: Foo = Foo(5) println(bar.square) // => 25 Compiles down to (the moral equivalent of) object Foo { def square(x: Int): Int = x * x } val bar: Int = 5 println(Foo.square(bar)) // => 25 If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory).
        pjmlp 7y ago
        Neither of those represent the same semantics of: inline class { ... ] Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.
        Nullabillity 7y ago
        You're correct that the Scala version isn't ABI-compatible. But Scala doesn't care about ABI between minor releases anyway, so that probably wouldn't stop them from changing it to align with Java. There is also precedence for this, Scala 2.12 changed the encoding of lambdas from anonymous classes to Java 8's invokedynamic.

bitL 7y ago

SUN was supposed to be here forever as well...

zmmmmm 7y ago

That cuts both ways though. If JetBrains goes away or something shifts their corporate interest away from that then Kotlin has zero support at all. Whereas other languages are built on grass roots foundations. It's certainly unlikely in the short term but it's hard to say long term about the future of any company.