Kotlin 1.2 Released: Sharing Code Between Platforms

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<String>) {
      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 `expect` and `actual` keywords (but primarily the latter) added unneeded verbosity in the Kotlin Slack awhile back and was pretty much shrugged off, despite folks on the Kotlin team admitting that they exist in part to make the IDE's job easier, but weren't actually necessary.

It leaves a sour taste in my mouth, but I suppose it might be because I'm familiar with projects in C/C++ where, if a symbol goes undefined, the compiler/linker is smart enough to tell you that without being hand-held.

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
     public function print(s : String) java.lang.System.out.println(v);
  #end

That method only exists on the java target, and the compiler will complain otherwise.

Conditional compilation also allows for more fine-grained support of multiple targets:

  #if java
     public function print(s : String) java.lang.System.out.println(v);
  #elseif js
     public function print(s : String) console.log(v);  // as a simple example
  #end

This makes a cleaner organizational distinction between extern code that must remain target specific, and true cross platform code that can be called on any of the supported targets. Editors can pick up on this very easily and provide early warnings as you are typing, and doc generators can also inspect these directives and show api availability between targets in the rendered docs.

(self-disclosure: Haxe compiler contributor)

  #if java
     public inline function print(s : String) java.lang.System.out.println(v);
  #else
     public inline function print(s : String) Sys.println(s); // most of the time basic ops are covered by std lib.     
  #end

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.

I really hope this release means https://github.com/JetBrains/kotlin-native will get brought onto the express lane! It's either Kotlin or Swift that will go full cross platform for end user applications (JS/Android/iOS) and Kotlin right now has the advantage! (Swift doesn't officially support the Web story.)

> "Working with the Command Line Compiler"

https://kotlinlang.org/docs/tutorials/command-line.html

> "We can download it from GitHub Releases."

https://github.com/JetBrains/kotlin/releases/tag/v1.2

404

    $ which kotlinc
    /opt/src/kotlin-1.2.0/bin/kotlinc

    $ kotlinc
    /usr/bin/env: ‘bash\r’: No such file or directory

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?

I will still bet for scala, at least it makes more sense for me considering the usage of Apache Spark / Flink