
Kotlin 1.2 Released: Sharing Code Between Platforms - dayanruben
https://blog.jetbrains.com/kotlin/2017/11/kotlin-1-2-released/
======
EddieRingle
Multiplatform docs here:
[https://kotlinlang.org/docs/reference/multiplatform.html](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.

~~~
pjmlp
You are not alone.

I also believe they could have manage it without polluting the code with
expect and actual.

Probably the compiler would need some extra work to do the matching.

~~~
oblio
True, but on a scale of 1 to 10, with 10 being amazing, Kotlin is quite high,
maybe an 8, and your point is only a minor nit.

~~~
noncoml
You seem very fond of Kotlin.

I hear a quite a bit about it lately, but as I haven't had the chance to play
with it yet, I was wondering why would one choose it over Scala.

~~~
barrongineer
I find it to be more pragmatic and easier on the eyes. It's easier to learn
and also being adopted by more mainstream ecosystems like Spring, Android,
Gradle, etc. IDE support is obviously top-notch as well.

------
jdonaldson
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)

~~~
yole
In Kotlin, every module contains either common code or platform-specific code.
I'm not sure why you consider the module-level distinction to be less clean
than being able to mix common and platform-specific code randomly within a
single file.

And your example shows that there is no way to verify that each module
provides a consistent API.

~~~
jdonaldson
> In Kotlin, every module contains either common code or platform-specific
> code. I'm not sure why you consider the module-level distinction to be less
> clean than being able to mix common and platform-specific code randomly
> within a single file.

Module-level distinctions are per-target. It doesn't get any more clean and
clear than that, does it? The trade off is that it's a bit limiting.
Conditional compilation is where you can start to pick and choose
targets/features and handle more sophisticated cases.

> And your example shows that there is no way to verify that each module
> provides a consistent API.

This is easy to do by providing a common interface definition and a simple
build class that targets each language you're interested in. It's a good idea
in a formal testing suite for a complex library.

I only do that in a handful of projects though, most of the time cross-target
code is just a few special exceptions. In that case, you'd call out the
special case, and then use the #else directive for the rest:

    
    
      #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
    

FWIW I've "inlined" things here with the keyword. This lets you alias cross-
platform methods like this without extra function call overhead.

------
pjmlp
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.

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

~~~
pjmlp
Thanks for the update.

------
arithma
I really hope this release means [https://github.com/JetBrains/kotlin-
native](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.)

------
igouy
> "Working with the Command Line Compiler"

[https://kotlinlang.org/docs/tutorials/command-
line.html](https://kotlinlang.org/docs/tutorials/command-line.html)

> "We can download it from GitHub Releases."

[https://github.com/JetBrains/kotlin/releases/tag/v1.2](https://github.com/JetBrains/kotlin/releases/tag/v1.2)

404

~~~
yole
We've fixed this already; the fix is being deployed. The correct URL is
[https://github.com/JetBrains/kotlin/releases/tag/v1.2.0](https://github.com/JetBrains/kotlin/releases/tag/v1.2.0)

~~~
igouy

        $ which kotlinc
        /opt/src/kotlin-1.2.0/bin/kotlinc
    
        $ kotlinc
        /usr/bin/env: ‘bash\r’: No such file or directory
    

Seems to have been saved with MS Win line ends, which causes a problem with
bash on Ubuntu.

~~~
sigzero
Do you have to use bash to run it? Seems like that should have used sh to get
the biggest install base (Groovy does this).

------
continuations
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?

~~~
yole
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.

~~~
continuations
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?

~~~
yole
You can't reuse UI code between iOS and Android. You do have the ability to
reuse the business logic code (domain models and so on).

~~~
maxdo
Great idea , but for many react apps (both native and JS) domain models
doesn’t exists. Redux + graphql apps let me eliminate even more logic. So what
we actually share between react native and react JS apps are : graphql
queries, reducers, saga middleware. The rest is just UI. In my usecases there
is nothing to share using Kotlin.

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

