Hey, since you asked about use cases for Kotlin/Wa...

# webassembly

[sdeleuze]

Hey, since you asked about use cases for Kotlin/Wasm previously, I continue to refine mine from a server-side POV.

Why not using Kotlin/JVM? Multiple reasons:
• Reduce the size of the stack necessary to run my app or function, see https://www.infoq.com/articles/arm-vs-x86-cloud-performance/
• Not being tied to Oracle could be another one
• Interoperability, for example by being able to use Wasm as a kind of universal deployment format (suitable for server-side, frontend or IOT) or interrop with native technologies
I would like to be able to use Kotlin/Wasm for my high level server-side application logic instead of Node/JS (using Ktor/Wasm ?) with the kind of use case described in that video

https://youtu.be/0MyCj17xaQQ▾

. Interop between Rust for low level components and Kotlin/Wasm for high level logic would be amazing. I know WebAssembly modules are too low level, WASI is maybe not enough. What if Wasm components could be the right incarnation of that ? https://radu-matei.com/blog/intro-wasm-components/

Anyway, that kind of server-side arrangement combined with Kotlin/Wasm + Rust on frontend as well would be a game changer combination.

[Jilles van Gurp]

These are kind of soft/non functional requirements. Harder requirements for WASM:

• Needing startup time measured in milliseconds. Edge computing, lambda style server-less architectures, etc. The JVM scales up but not down.
• Command line tools and other short lived processes.
• Targeting embedded or limited resource environments.
• System programming requiring deep integration with system libraries, kernels, etc.
These have in common that Kotlin is still relatively a niche language for those and that WASM is being used for them. No reason why Kotlin could not be a systems programming language. IMHO it's much better than Go for this and probably a lot easier to deal with than Rust. Never mind C/C++.

[Svyatoslav Kuzmich [JB]]

Thanks for detailed use cases and requirements!

I agree that in some situations Wasm would be preferable to JVM on server-side. We would want to dive deeper into this once Web frontend use case is covered. I would imagine there a big overlap with K/Native, and both would have their advantages.

As far as using Wasm in systems and resource-constrained programming, we, frankly, don't have near future plans to focus on it specifically. Having said that, we want to build a flexible tech, so people could apply it any way they see fit. Any input on what would improve systems programming with Kotlin is welcome!

[sdeleuze]

I think I try to share my vision of what could be the sweet spot for Kotlin/Wasm outside of just the Frontend rather than requirements where various languages could fit.

In the context of Wasm, what we call system programming is a moving target, the system will be less tied to the OS even if it will reuse a lot of Unix system programming concepts. For traditional system programming, Kotlin/Native is probably a better fit.

With GraalVM native images, which is a topic where I am deeply involved, the JVM can scale down and start in ms as well, or be used for command line tools. That’s the reason why I highlight the global vision where Wasm allows isolation with a thiner stack. There are more like the security model, etc.

I highlight interop with Rust because they are at the forefront of the WebAssembly interop story and for low level libraries, I see a lot of values to be able to use Rust and Kotlin together, they are very complementary.

With TypeScript the JS ecosystem has begin to move towards more statically typed languages, Wasm opening the door to non JS based languages and being designed for statically typed languages, I see that as a huge opportunity for Kotlin.

I see Go as a kind of tradeoff solution (GCed but not as expressive as Kotlin and not usable for low level code like Rust/C/C++), I prefer a platform where I have a real expressive language for business code like Kotlin with an opportunity to use Rust for performance critical parts if needed.

Also I think we are at a point where Kotlin need to reach a wider developer base than just JVM/Android developers. A good interop with Rust which is not tied to a single big company and is used in various Wasm infrastructure projects could resonate with a lot of people in the Wasm ecosystem IMO.

Kotlin can’t dominate Java on the JVM outside of Android, Kotlin can’t dominate JS/TypeScript with Kotlin/JS, but I think there is opportunity with Kotlin/Wasm to be a major player with the right non-JS interop story. Wasm is closer to native semantics than JS ones, so while I don’t disagree that Web APIs interrop is important, I believe that the capability for high level languages to be able to have a great interop with low level ecosystems like Rust one exposed via Wasm components will be from my POV one of the most important differentiators.

[Svyatoslav Kuzmich [JB]]

Wasm component model sounds very promising, indeed. It is currently at a very early stage, we'll have to wait a little bit.

[napperley]

Do note that K/N already covers some resource constrained programming areas (eg Embedded GUI), if you count SBC's as one of the resource constrained environments. One would need to ensure that there is minimal overlap between K/W and K/N, otherwise it will create massive confusion.

[sdeleuze]

Pure speculation since I am not in the Kotlin team, but I have the feeling that the abstractions exposed won’t be the same :
• Kotlin/Native is using OS abstraction, has interrop with C, is not designed for the web and provides its own GC
• Kotlin/Wasm will use WebAssembly abstractions and Wasm GC, will provide access to Web APIs and JS interrop when run in the browser, and hopefully will provide interrop in the future with other languages via Wasm components
So if we think about interrop with AI libraries for example, K/N will use C interrop while K/W will hopefully use Wasm components. That’s maybe not obvious yet, but if you imagine a repository of Wasm components reusable in various languages, the fact that they will use an ubiquitous deployment format, that interop will be not limited to C but will also allow to target C++/Rust and others, and the security benefits, I think Kotlin/Wasm has much more potential than Kotlin/Native for server-side and embedded systems in the long run.

The building blocks are not available yet but when they will, the languages that have anticipated the right WebAssembly support like Kotlin or Rust can IMO dominate that space.

[Svyatoslav Kuzmich [JB]]

AFAIK, Wasm components would have a bit more overhead on the boundary compared to direct C interop. IT looks like a great solution for using single API from any language, but with popular libraries we might want to have a specialized solution that would bypass component model.

[kailan]

Here at Fastly I am very excited about the prospect of running Kotlin on the edge. Right now the most performant language on our Wasm platform is Rust, but the learning curve for new developers is significant.

We do support JavaScript but this comes with the overhead of also shipping a JS engine to the edge. Kotlin/Wasm would be a fantastic middle ground for developer experience and performance, especially with the surge of Kotlin developers in recent years thanks to Android’s adoption

[corneil]

I see a lot of opportunity with Cloudflare making wasm availabe at the edge. You can build responsive frontend components or a controller layer of the backend maybe even leveraging GraphQL and intelligent caching.
IoT goes unsaid.
Having a simple way to have shared models and behaviour gives you a leg up on people using different languages for various models and layers.

[napperley]

Sharing of backend logic is one of Kotlin's strengths/fortes over the competition (with WASM that would include C#, Rust, JS etc).

[Tristan]

@sdeleuze is that something you thought about too? https://news.ycombinator.com/item?id=30020121

[sdeleuze]

I think Wasm will deeply impact k8s ecosystem, but I see both as complementary since are not at the same level. But titles like « WebAssembly : the new JVM ? » or « WebAssembly : the new Docker ? » are maybe less clickbait 😉

[corneil]

@sdeleuze I agree. WASM is like a new kind of container/VM. It's different in that you get platform specific services depending on where it is executing. We're going to see them as providing portable mobile apps. We're going to see the provide apps and services on the edge. The possibilities are endless. As long as we the community maintain discipline and not have a npm mess of dependencies. That's why I think Rust and Kotlin are to great languages for WASM because they come with some inherent discipline

[Jilles van Gurp]

There are a couple of other use cases. Wasm seems to be used whenever there's a need to isolate things like plugins. VS Code has lots of plugins and at this point probably quite a few are WASM based. Jetbrains has lots of potentially cross platform code in the form of multi platform libraries already. And of course lots of software related to development tooling. VS Code and the wider ecosystem of editors that use the same plugin APIs are interesting to target for them. Wasm would be the way to do it. And of course in the browser, WASM could end up being a more efficient way to run Kotlin than kotlin-js is currently.

IMHO the key thing is actually going to be the multi platform library ecosystem. There are a few blank spots in there that are also holding back kotlin native (e.g. the lack of good multi-platform file and IO libraries).