https://kotlinlang.org logo
Title
f

fitzoh

02/15/2019, 8:46 PM
I know @sdeleuze is doing a great job of selling it, but is it officially on the radar/roadmap for Jetbrains?
1
n

napperley

02/15/2019, 10:52 PM
Excellent question. There is way too much focus with Kotlin Native on the iOS development side. Kotlin Native's focus needs to be spread to multiple areas, especially WASM which will have a much bigger impact, and provide way more benefits for Kotlin than iOS.
g

gildor

02/16/2019, 4:04 AM
I disagree. At the moment iOS is much-much bigger selling point than wasm and much bigger market for Kotlin Wasm potentially is interesting but to be honest for now is on early stage
Also it's completely not clear that wasm backend should be based on K/N. As I understand point of Sebastien, he actually thinks that separate backend with better js support is better solution than usage of llvm for this
s

sdeleuze

02/16/2019, 8:18 PM
I see WebAssembly as a platform at the intersection between Native, the Web and what has made the success of Node on server side. The fact that it is a web standard makes it a place where big companies like Google, Oracle or Apple can be involved but can't control everything like with app stores on mobile. For an independant actor like JetBrains, it could matters. I also think we need this kind of common platform for all usages : mobile/web/server/IoT. I keep thinking about how Kotlin could take advantage of WebAssembly. The "funny" thing is that WebAssembly platform matches with a kind of mix between Kotlin/JS and Kotlin/Native. It matches with Kotlin/JS because it could be used as a dropin replacement for current JS code generated asap WebAssembly will have GC and Web API exposed. But if you just use WebAssembly for that you are doing with JS, you get it wrong. WebAssembly is conceptually more close to Kotlin/Native. Look what https://github.com/AssemblyScript/assemblyscript is doing. They are using a more constraint subset of TypeScript to generate very small and efficient WebAssembly code. If they were just using regular TypeScript they would generate bloated WebAssembly and the interest would be close to 0. WebAssembly is a native technology of a special kind and the language need to adapt to it, like Kotlin/JVM was originally carefuly crafted for the JVM. Kotlin/WebAssembly if it exists some day would be IMO a mix of Kotlin/JS and Kotlin/Native. It is close of Kotlin/Native semantics, but it would need to have a Kotlin/Native -> Kotlin IR -> Binaryen toolchain (see https://github.com/WebAssembly/binaryen). LLVM is not a good fit at all, especially for WebAssembly GC. The reason why I think it has a huge potential on server-side is that with serverless, microservices, and more generally the fact that workload run in the Cloud, I see a very deep move toward native technologies. GraalVM native images which has been graduated by Oracle as a first class product is a good example, Kotlin/Native, Swift on server side are also other ones. The GraalVM native images case is pretty interesting. The JVM has been designed to run workload of multiple applications on production, now we see that it consumes too much in the Cloud where JVM are isolated in containers, so we are going to use it only for development, and our JVM bytecode will be translated to native code on the Cloud platform. To me that mainly means that nowadays, we are able to build technologies that allow developers to be efficient to develop complex applications and that can run efficiently, start fast, consume less memory via native runtime.
But there are drawbacks that you can see on Kotlin/Native or GraalVM native image : compilation is slow, generated artifact are platform specific, welcome to the new world !!! That's where WebAssembly has a huge potential. IMO it is what the JVM has always wanted to be. It has the required characteristic to be a universal target format that can be used to deploy your application on the Cloud, on mobile, IoT, desktop, web, etc. Compilation is fast. You can run isolated WebAssembly applications with much less ressources and complexity that what we do currently where we ship one OS per application. The question is: what language will matter in this platform. Rust is great for high performance library but the language has far too much noise for using it for regular entreprise software development. AssemblyScript is interesting but I think WebAssembly is an opportunity to avoid building on top of JavaScript. Swift, Go (which will get generics and better error management shortly) and Kotlin are the kind of language that could be a good fit with WebAssembly if they manage to translate efficiently to WbAssembly code (which is not yet the case currently). Kotlin is born from the JVM so it is not a perfect fit for WebAssembly today, but with WebAssembly GC coming, as well as other features and with the open mind of Kotlin team that adapts this language to native in Kotlin/Native, I think there is a way. I know Jetbrains/Kotlin team has not always a deep frontend culture (most dislike JavaScript), but think about IDEA on the long term. What is the plan to compete with VS Code? Desktop JVM is a dead platform, generating platform specific artifacts is just a pain to maintain and to use. It is maybe reassuring to continue joking about the amount of memory/CPU consumed by Electron/Slack/whatever, but the truth is that WebAssembly makes it possible to build an IDE with the power of IDEA that run in the browser (see what the AutoCAD team has done https://twitter.com/autocad/status/993963826914648064 and the post MVP roadmap https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/) and that could be easily packaged as desktop application. I know we are not here yet, but to me that makes no doubts that the future of IDE and complex applications like that is using WebAssembly to build and deploy them.
3