7 ms·

Good job reaching a stable release. I have a Kotlin microframework that never made it past hobby-level stability[1]. One thing I found out is that you really

by danneu 9y ago

Good job reaching a stable release. I have a Kotlin microframework that never made it past hobby-level stability[1]. One thing I found out is that you really have to write a library in Java if you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively one-way interop. I also found async programming to be really hard in Java which is why I wrapped Jetty. Meanwhile async APIs like Netty and Undertow were completely exotic to me. For example, I couldn't figure out how to go from `Request -> Response` to `Request -> Promise<Response>` by wrapping Netty. One thing I did find out was that Kotlin is probably my favorite language. Very similar to Swift, though I wish you could re-open 3rd party classes to make them conform to additional interfaces which you can do with Swift protocols. I also never figured out how to hot reload code without restarting the server. Even JRebel didn't work for me. Looking at Jetbrains' own framework, their code that implements reloading is pretty intimidating[2]. OP is also the author of https://github.com/tipsy/j2html https://github.com/tipsy/j2html which I've been using in my own small servers. I couldn't figure out a better way to get typesafe html templating in the ecosystem. [1]: https://github.com/danneu/kog https://github.com/danneu/kog [2]: http://ktor.io http://ktor.io

tipsy- 9y ago
Thanks! Yeah, I had to leave a few parts as Java in order to get the interop right. Anything that takes an functional interface needs to be Java, so the main API entry points are all Java. Most other classes and all internal code is Kotlin. I originally wrote it all in Java, and ended up with about 30% less code after I rewrote it to Kotlin.
hota_mazi 9y ago
> though I wish you could re-open 3rd party classes to make them conform to additional interfaces which you can do with Swift protocols. Mmmh really? I just reread the Protocol section of the Swift documentation and I didn't find this. If I have a class I can't modify and that doesn't conform to protocol `Foo`, can I make it conform to that protocol? A similar feature is being considered for Kotlin since this opens up all kinds of interesting mechanisms (notably, ad hoc polymorphism) but I don't see how to do that in Swift right now.
- faical 9y ago
  > If I have a class I can't modify and that doesn't conform to protocol `Foo`, can I make it conform to that protocol? Yes, you can.
  - fauigerzigerk 9y ago
    Not sure if that's a good thing though. I read some of the Swift standard library source code and found it very difficult to piece together all the stuff added by extensions, where they come from and where the original class definition is. Obviously, it's going to be easier if you have written the code yourself, but what if someone else needs to read it?
  - hota_mazi 9y ago
    Can you point to the relevant documentation section? I couldn't find it.
stewbrew 9y ago
"One thing I found out is that you really have to write a library in Java if you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively one-way interop." Could you please explain this.
- dradtke 9y ago
  I think it means that a library written in Kotlin is difficult or impossible to use from Java.
  - EddieRingle 9y ago
    Not really true from my experience. For example, here's a Markdown library written in Kotlin that you can use with a plain Java interface: https://github.com/valich/intellij-markdown https://github.com/valich/intellij-markdown
  - edem 9y ago
    No no no no. Kotlin provides a lot of tools to make your library usable from Java and it works.
    - pdpi 9y ago
      You have to write your Kotlin anticipating it'll be called from Java though (e.g. by using SAM interfaces instead of function types for your arguments)
      - lmm 9y ago
        Is Kotlin's function not an SAM interface? I'm pretty sure Scala's is.
      - edem 9y ago
        This does not mean that it is a one-way interop. When you write it the right way, it will work from Java.
tsvetkov 9y ago
> Java -> Kotlin is effectively one-way interop Could you provide some more details? I'm a bit surprised by your statement because Kotlin team has put a lot of effort into providing mostly seamless two way interop. Kotlin project itself is ~50% Java (specifically to test interop).
- edem 9y ago
  You are surprised because it is not true. I can prove that you can write two-way interop just check the library I've written and posted above.
  - danneu 9y ago
    You can write two-way interop -- I didn't mean to suggest otherwise. But there are Kotlin features that don't map like type-safe @Dsl's which puts you in a position where you have to make concessions for interop.
    - edem 9y ago
      Now that is true. You also can't use reified generics (which is a bit hacky anyway).
      - PopsiclePete 9y ago
        "It totally works...except for A, B....oh yeah and C, but C kinda sucks....well D is awful too, you should never use D...." So basically, he was right, and you weren't. There is no seamless 2-way interop, yes?
        hibbelig 9y ago
        I don't understand this sentiment. I understand Kotlin has more features than Java, and of course it's tough to call the advanced things from Java. At least so I would think.
        edem 9y ago
edem 9y ago
This is definitely NOT TRUE. I've written a library which is used from both Java and Scala and it just works. Here: https://github.com/Hexworks/zircon https://github.com/Hexworks/zircon Just because you didn't manage to get it working does not mean that interop is not two-way.
- deleted 9y ago
  [deleted]
lmm 9y ago
> One thing I found out is that you really have to write a library in Java if you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively one-way interop. Hah. As someone who remembers the early days of Scala - the promise of seamless interop followed by the realisation that a language-idiomatic API requires much more than being able to seamlessly invoke a method - I can't say I'm surprised. > One thing I did find out was that Kotlin is probably my favorite language. Very similar to Swift, though I wish you could re-open 3rd party classes to make them conform to additional interfaces which you can do with Swift protocols. Maybe look at Scala; implicit conversions offer an easy-but-somewhat-hacky way to do that, while typeclasses are a very elegant general solution that a lot of libraries are based on these days.

by danneu 9y ago

tipsy- 9y ago

Thanks! Yeah, I had to leave a few parts as Java in order to get the interop right. Anything that takes an functional interface needs to be Java, so the main API entry points are all Java. Most other classes and all internal code is Kotlin. I originally wrote it all in Java, and ended up with about 30% less code after I rewrote it to Kotlin.

hota_mazi 9y ago

> though I wish you could re-open 3rd party classes to make them conform to additional interfaces which you can do with Swift protocols. Mmmh really? I just reread the Protocol section of the Swift documentation and I didn't find this. If I have a class I can't modify and that doesn't conform to protocol `Foo`, can I make it conform to that protocol? A similar feature is being considered for Kotlin since this opens up all kinds of interesting mechanisms (notably, ad hoc polymorphism) but I don't see how to do that in Swift right now.

faical 9y ago
> If I have a class I can't modify and that doesn't conform to protocol `Foo`, can I make it conform to that protocol? Yes, you can.
- fauigerzigerk 9y ago
  Not sure if that's a good thing though. I read some of the Swift standard library source code and found it very difficult to piece together all the stuff added by extensions, where they come from and where the original class definition is. Obviously, it's going to be easier if you have written the code yourself, but what if someone else needs to read it?
- hota_mazi 9y ago
  Can you point to the relevant documentation section? I couldn't find it.

stewbrew 9y ago

"One thing I found out is that you really have to write a library in Java if you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively one-way interop." Could you please explain this.

dradtke 9y ago
I think it means that a library written in Kotlin is difficult or impossible to use from Java.
- EddieRingle 9y ago
  Not really true from my experience. For example, here's a Markdown library written in Kotlin that you can use with a plain Java interface: https://github.com/valich/intellij-markdown https://github.com/valich/intellij-markdown
- edem 9y ago
  No no no no. Kotlin provides a lot of tools to make your library usable from Java and it works.
  - pdpi 9y ago
    You have to write your Kotlin anticipating it'll be called from Java though (e.g. by using SAM interfaces instead of function types for your arguments)
    - lmm 9y ago
      Is Kotlin's function not an SAM interface? I'm pretty sure Scala's is.
    - edem 9y ago
      This does not mean that it is a one-way interop. When you write it the right way, it will work from Java.

tsvetkov 9y ago

> Java -> Kotlin is effectively one-way interop Could you provide some more details? I'm a bit surprised by your statement because Kotlin team has put a lot of effort into providing mostly seamless two way interop. Kotlin project itself is ~50% Java (specifically to test interop).

edem 9y ago
You are surprised because it is not true. I can prove that you can write two-way interop just check the library I've written and posted above.
- danneu 9y ago
  You can write two-way interop -- I didn't mean to suggest otherwise. But there are Kotlin features that don't map like type-safe @Dsl's which puts you in a position where you have to make concessions for interop.
  - edem 9y ago
    Now that is true. You also can't use reified generics (which is a bit hacky anyway).
    - PopsiclePete 9y ago
      "It totally works...except for A, B....oh yeah and C, but C kinda sucks....well D is awful too, you should never use D...." So basically, he was right, and you weren't. There is no seamless 2-way interop, yes?
      - hibbelig 9y ago
        I don't understand this sentiment. I understand Kotlin has more features than Java, and of course it's tough to call the advanced things from Java. At least so I would think.
      - edem 9y ago

edem 9y ago

This is definitely NOT TRUE. I've written a library which is used from both Java and Scala and it just works. Here: https://github.com/Hexworks/zircon https://github.com/Hexworks/zircon Just because you didn't manage to get it working does not mean that interop is not two-way.

deleted 9y ago
[deleted]

lmm 9y ago

> One thing I found out is that you really have to write a library in Java if you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively one-way interop. Hah. As someone who remembers the early days of Scala - the promise of seamless interop followed by the realisation that a language-idiomatic API requires much more than being able to seamlessly invoke a method - I can't say I'm surprised. > One thing I did find out was that Kotlin is probably my favorite language. Very similar to Swift, though I wish you could re-open 3rd party classes to make them conform to additional interfaces which you can do with Swift protocols. Maybe look at Scala; implicit conversions offer an easy-but-somewhat-hacky way to do that, while typeclasses are a very elegant general solution that a lot of libraries are based on these days.