Add Support For Kotlin Native

[napperley]

Although this runtime (runtime-kotlin) supports Kotlin JVM there is a case to be made for adding support for Kotlin Native. As you might be aware the JVM isn't optimised/designed for Serverless applications due to their performance characteristics/requirements:

• Quick start up time
• Low memory usage
• Small code size
• Minimal software dependencies
• Quick response time

All points listed above are also applicable to CLI applications which is another area the JVM isn't optimised/designed for. There is a technical presentation that provides a overview of Kotlin Native, including its performance aspects.

The Serverless performance issues with the JVM become clear when looking at some Serverless benchmarks comparing Kotlin JVM to Go. With the way the JVM is progressing developing Serverless applications that rely on the JVM is untenable (not feasible for the long term). Already some organisations like Pivotal (heavy adopter of Kotlin for server-side development) are exploring the use of Kotlin Native over Kotlin JVM as the preferred/best way to develop Serverless applications for the "long term".

Since Kotlin Native is LLVM based it would likely not require IBM to do a lot of work (IBM Cloud Functions already supports Swift which is also LLVM based) in order to add support. Kotlin Native already works on Open Whisk.

[csantanapr]

Thanks for the information @napperley this is very insightful

I think is worth looking into it even if it means havin the option to choose to create the action for both methods
—kind Kotlin or Kotlin-jvm

I’m guessing people might want to use jvm when they use libraries or dependencies in java/scala right?
And native only when all the code is native and compiled down ?

[napperley]

Also worth mentioning that Kotlin can target the Web Browser via Kotlin JS. With that Kotlin targets three platforms (JVM, JS, and Native) so it wouldn't be enough for a user to just select Kotlin as the language. There would need to be a option for Platform (available options would vary depending on the language that is selected).

@csantanapr - You are correct in saying one of the reasons people would stick with the JVM is because of the large ecosystem (can be a double edged sword). This is OK in a very small number of Serverless use cases where performance isn't important, and business's don't mind paying potentially large bills. Most Serverless use cases do require good performance, which makes using the JVM (including the ecosystem) very unfavourable.

Serverless is still a young area of software development, which does many things differently from traditional server-side development. Many individuals and business's run into trouble trying to use technologies (i.e. JVM and its ecosystem) that aren't designed for Serverless development, and often end up with poor performance as a result. This is where native technologies like Kotlin Native are a better fit because of their performance characteristics as mentioned in the first comment. Also there isn't a need to deal with a legacy ecosystem which isn't designed with Serverless in mind.

Building up a ecosystem designed for Serverless would require quality over quantity. Small ecosystems are much more desirable, and this would be very favourable for Kotlin Native. Check out this Kotlin Native example developed by a person from Google, which provides a glimpse into what can be achieved with Kotlin Native on the server end.

[csantanapr]

@napperley No disagreement there, that running kotlin on serverless the optimal way would be pure native kotlin that would be the ideal situation.

Thanks for the pointer to the native example, that's very helpful as building block to the create the native openwhisk kotlin image.

+1 on having an option to use kotlin native for openwhisk actions.

[napperley]

A good strategy for building up the Kotlin Native ecosystem (incl for Serverless) would be to port some JVM libraries/frameworks (including some Kotlin based ones - eg http4k) that don't require too many changes, and are suitable for Serverless after making some small changes. Kotlin (starting with version 1.2) has a multi-platform system that makes it easier for Kotlin projects to target multiple platforms via the multi-platform approach. Already there are some architecture best practises that have been developed to cover this approach.

The native example as mentioned earlier would greatly encourage Kotliners (Kotlin developers) to try out Kotlin Native for Serverless development, since the example looks very similar to some JVM libraries/frameworks (like Spark Java, Ktor, http4k, Vert.x etc). Also Kotliner's wouldn't need to worry about memory management with Kotlin Native programs/libraries using ARC (with cyclic collector), which is very similar to what Python uses (reference counting).