Live data from Hacker News

Kotlin 1.2 Released: Sharing Code Between Platforms

blog.jetbrains.com

31–40 of 41 posts

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#31

Multiplatform docs here: https://kotlinlang.org/docs/reference/multiplatform.html Example from the docs: // Common module package org.jetbrains.foo expect class Foo(bar: String) { fun frob() } fun main(args: Array ) { Foo("Hello").frob() } // JVM module package org.jetbrains.foo actual class Foo actual constructor(val bar: String) { actual fun frob() { println("Frobbing the $bar") } } I brought up how I thought the `…

That's silly. I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity. I was thinking about using Kotlin for multiplatform stuff but now I'll likely look elsewhere...

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#33
post #14

Earlier quoted context omitted.

You can do isomorphic (server-side and client-side) rendering in Kotlin. For mobile UI, you can build native UIs in Kotlin for Android and for iOS, but the UI code will be different for each platform, built on the native API of the corresponding platform. At this time we have no plans to build a solution for reusing UI code between mobile platforms.

If I can't reuse code between iOS & Android then what is the benefit of using Kotlin over just building mobile apps in Java & Swift?

They said UI code. You shouldn't be reusing that anyway. You should be writing stuff to take advantage of the native platform.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#34
post #27
post #25

Eclipse plugin is stuck on 1.1.1, 20 March 2017. I understand JetBrains would like everyone to use InteliJ and they aren't required to support other IDEs, but it prevents adoption on many IT departments that only allow for Eclipse on their dev images.

We're now resuming the development of the Eclipse plugin, and you'll see new updates very soon.

Thanks for the update.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#35
post #14

Earlier quoted context omitted.

You can do isomorphic (server-side and client-side) rendering in Kotlin. For mobile UI, you can build native UIs in Kotlin for Android and for iOS, but the UI code will be different for each platform, built on the native API of the corresponding platform. At this time we have no plans to build a solution for reusing UI code between mobile platforms.

If I can't reuse code between iOS & Android then what is the benefit of using Kotlin over just building mobile apps in Java & Swift?

IMO, It's just a different approach to the idea than the React world. I would assume the idea here is that you always want to write your UI layer "natively" in order to take full advantage of platform-specific performance accelerations/hardware APIs, but the entire stack underneath what's actually rendering visual components would be shared.

It forces you to start out more modular between your UI code and domain logic code, whereas React (& React Native) leaves the door open right at the start for tight coupling between UI code & domain logic, unless you expressly build this separation into your initial architecture.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#36

I really like some of Kotlin's decisions, but I prefer Haxe's approach to this. For single target code, you can prefix the class module with the platform tag (e.g. "js" or "java"). These module names are reserved within the compiler and any code therein is restricted to their respective targets. Another way is to use conditional compilation markers to indicate specific target-compatible boundaries. E.g. #if java publ…

How good is Haxe? What are its issues, pros/cons? I am looking for something similar; Kotlin was one choice though after today I am not sure about it anymore, so what do other frameworks offer?

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#37
post #31

Multiplatform docs here: https://kotlinlang.org/docs/reference/multiplatform.html Example from the docs: // Common module package org.jetbrains.foo expect class Foo(bar: String) { fun frob() } fun main(args: Array ) { Foo("Hello").frob() } // JVM module package org.jetbrains.foo actual class Foo actual constructor(val bar: String) { actual fun frob() { println("Frobbing the $bar") } } I brought up how I thought the `…

That's silly. I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity. I was thinking about using Kotlin for multiplatform stuff but now I'll likely look elsewhere...

>I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity

Aka pragmatic.

But it can all be fixed -- you can do a hostile fork and improve upon their code together with other non-lazy developers. You'd get much more done than the Kotlin team, being non-lazy and all...

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#38
post #37
post #31

Earlier quoted context omitted.

That's silly. I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity. I was thinking about using Kotlin for multiplatform stuff but now I'll likely look elsewhere...

> I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity Aka pragmatic. But it can all be fixed -- you can do a hostile fork and improve upon their code together with other non-lazy developers. You'd get much more done than the Kotlin team, being non-lazy and all...

Hostile fork has a low chance of survival; for one you should wait until Google cuts all vital pieces off JetBrains as they are trying for the past few years anyway, yet making JetBrains people somehow flattered about it... MS is at least openly trying to kill them.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#39

Multiplatform docs here: https://kotlinlang.org/docs/reference/multiplatform.html Example from the docs: // Common module package org.jetbrains.foo expect class Foo(bar: String) { fun frob() } fun main(args: Array ) { Foo("Hello").frob() } // JVM module package org.jetbrains.foo actual class Foo actual constructor(val bar: String) { actual fun frob() { println("Frobbing the $bar") } } I brought up how I thought the `…

requirement outjection vs. dependency injection

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#40

How does Kotlin multiplatform compare to React? In React I can: - server side render a page to HTML and send it to browser, or - send down the React code as JS and render in browser, or - use React Native to write sorta native Android/iOS apps and reuse some of my JS codebase Does Kotlin cover the same use cases of server-side render & browser render & native mobile apps?

Why do you compare Kotlin against React? They can work together: https://blog.jetbrains.com/kotlin/2017/04/use-kotlin-with-np...

Write your React code in Kotlin, compile to JS and use it everywhere where React is supported.

Post reply on HN