6 ms·

The potential of Kotlin/WASM

60 points by sdeleuze 4y ago

sdeleuze 4y ago
This new blog post explores the huge potential of Kotlin/Wasm and how WasmGC, WASI, WebAssembly Component Model and warg repositories could change how we develop applications.
gavinray 4y ago
Thank you for the work on KoWasm It's been exciting to watch the development of the new K2 compiler and Frontend-IR format Kotlin is no longer just a JVM language, but more like a frontend with targets that now span everything from JVM bytecode, JavaScript, native code with Kotlin Native, and WASM I'm really excited to see what the future holds for Kotlin and WASM in particular
- flykespice 4y ago
  Yet most of kotlin standard library is still functions extensions to Java package classes (jvm), if you filter out the function listing in the kotlin website to only implementations common across targets (Common tag), there is very little to be usable.
  - brianslp 4y ago
    Due to the nature of being a frontend-for-everything I think it's best to keep the stdlib's platform-specific functionality minimal.
  - tadfisher 4y ago
    Other platforms don't include Java's standard library, so it would be presumptuous to build one for each platform.
- jillesvangurp 4y ago
  It's increasingly a full stack language. I would say increasingly more so than javascript since it actually compiles down to native. So, you can use it in the browser, in the jvm, with node.js (not a great fit but it works), on edge networks or in lambda functions (with the native compiler or soon wasm), or on mobile devices. The main things holding kotlin native back have been the compiler and the library ecosystem. The compiler has been making a lot of progress over the last two years. And the library ecosystem has a growing number of high quality multi platform libraries. So, there's less need for wheel reinvention. Long term, given enough interest, it could start competing with Rust and Go for system programming type things. Right now, that's probably the weakest area for Kotlin but that is mostly because of the relatively immature library ecosystem around Kotlin native for this. IMHO the language actually fills a nice gap between Rust and Go. Easier than Rust, a bit more high level than Go. So far, Jetbrains seems more interested in mobile than in other use cases for kotlin native though. Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. There are some interesting libraries for Kotlin for this. But like with native this is all relatively immature and a bit niche at this point. Some interesting things you might not be aware off: - multi platform compose is a thing and as of recent releases it has an experimental IOS target as well. So, you can build desktop, android, web, and IOS capable applications now with using Kotlin. Unfortunately Desktop compose still depends on the JVM instead of using the native compiler. So, there's now a third alternative emerging next to Flutter and React Native for cross platform UI. - ktor server can now be used with the native compiler. So you now have two ways of producing native binaries for ktor via graal and the kotlin native compiler. Great for use with e.g. lambda functions as well. - kotlin scripting (KTS) is pretty nice and you can use it in more places than just Gradle. It works in Jupyter for example. Or you can generate github actions with it (we do this via krzema12/github-workflows-kt). - you can plugin wasm to kotlin (and lots of other languages) via extism.org. Haven't tried this but looks intriguing.
  - dunefox 4y ago
    > Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. Julia and R are esoteric? For Data Science? Also, Kotlin would be relatively low on the list of languages I would use for DS. F# is higher.
    - jillesvangurp 4y ago
      For normal programmers I mean. I know lots of programmers. None of which specialize in Julia or R. They are specialist tools. Python is more a language for generalists. Which is why it is so popular in this space. Kotlin fits more in that category.
slim 4y ago
disappointed that gilles.deleuze.fr does not get you anywhere
- rogue7 4y ago
  My thought exactly when I saw the domain name
- bouiaw 4y ago
  Good one ^^. Sadly not from my family even if he is one of my prefered philosopher.
  - slim 4y ago
    maybe redirect to webdeleuze.com :)
rektide 4y ago
> But WebAssembly becomes even more interesting when you take another perspective. What if Compose for Web, the multiplatform incarnation of Jetpack Compose used on Android, would leverage Kotlin/Wasm instead of Kotlin/JS to perform pixel-perfect Canvas based rendering? It would not really be very web like. It'd be more like Flash or a Java Applet. User extensions would all be broken. This is a new thing coming people. Now that we have wasm, the native-app folks are super jazzed about not only switching programming langauges, but getting rid of HTML and the DOM. The plan goes: we're replacing structure markup & hypertext of webapps with just-a-bunch-of-pixels, big canvases, that are purely computational constructs. Declarative information is getting blown up by imperative processes; this is how native apps are having their revenge against webapps. I have yet to see how any of this actually empowers or helps users: it seems like a huge downgrade, done purely to give developers alternative options. Maybe the experiences really are vastly better, maybe what we make is categorically different once we have this tech! But I really have a hard time (given what creativity we've had & seeing how quickly bootcamp folks come in & get hacking on the DOM) believing the DOM is really so horrible that it justified de-internet-izing the web & that turning it into a motion picture machine is warranted (as anything more than early exploration). The web starts with the HTML/DOM, and has been our computing world's greatest, most universal tower of Babel[1] that has held. I'm curious (and admittedly pretty terrified) to see who is happier/winners when we bring down the higher-level system, & treat it like a low level interface, like a big Canvas, like what was happening with Flash & Applets. Two other recent examples beyond Kotlin/Compose: Flutter/CanvasKit (which I commented on & got a reply from the lead about on these topics[2]), and Hixie's "Towards a Modern Web Stack"[3]. [1] https://unwindprotect.com/tower-of-babel https://unwindprotect.com/tower-of-babel https://news.ycombinator.com/item?id=34695638 https://news.ycombinator.com/item?id=34695638 [2] https://news.ycombinator.com/item?id=34527980 https://news.ycombinator.com/item?id=34527980 [3] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/preview?pli=1&resourcekey=0-bPajpoo9IBZpG__-uCBE6w https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696
- ericmcer 4y ago
  What does it really offer? Performance and flexibility? It will probably continue to be a niche for really specific high performance applications but the DOM will always exist as long as 99% of the internet is just viewing or uploading text/images/videos. The amount of experience and knowledge that has gone into fixing edge cases like accessibility, viewports, cross-browser support, security, etc. makes any kind of 'pure wasm' app a nightmare to maintain.
singularity2001 4y ago
Hello world is 1.5 MB but compiled surprisingly fast: less than a second (with grade running, couldn't test konanc -target wasm yet?) That's much better compilation time than kotlin/native:wasm Wasm types are currently inaccessible in JS and you can't feed js objects into wasm, hopefully that will change...
- bouiaw 4y ago
  Hello world with production artifact and Binaryen optimization produces a 128K Wasm file for now for https://github.com/vmware-labs/wasm-languages/tree/main/kotlin/browser-hello-world https://github.com/vmware-labs/wasm-languages/tree/main/kotl..., but the Kotlin/Wasm team has not tracked those data points recently so there are likely footprint regressions to fix. The size should be even smaller. They are going to have a look and also to enable Binaryen by default for production artifacts.
  - singularity2001 4y ago
    nice + thanks
Existenceblinks 4y ago
Yes please, backend people (and compiler folks) be united to try to catch up with the latest wasm proposals, we are pretty close now (also waiting for the 'stringref'). The future is treating DOM stuff as system thingy, so we can stop (except those who want to stay) writing JS/TS on the logic part. I'm optimistic we will have a better mental heath on developing web frontend in near future.
dhalucario 4y ago
I don't know if anyone else had the idea yet, but I would love to use Kotlin with Svelte on the frontend.
- Existenceblinks 4y ago
  At some point someone will figure out the wire up between the reactive part (thing like "signal") on wasm side and and propagate changes to the effect side to render DOM nodes.
- bouiaw 4y ago
  I would love to see a Svelte-like frontend framework natively designed for Kotlin/Wasm, not necessarily another Kotlin to JavaScript binding that feels like a second class citizen.

60 points by sdeleuze 4y ago

This new blog post explores the huge potential of Kotlin/Wasm and how WasmGC, WASI, WebAssembly Component Model and warg repositories could change how we develop applications.

gavinray 4y ago

Thank you for the work on KoWasm It's been exciting to watch the development of the new K2 compiler and Frontend-IR format Kotlin is no longer just a JVM language, but more like a frontend with targets that now span everything from JVM bytecode, JavaScript, native code with Kotlin Native, and WASM I'm really excited to see what the future holds for Kotlin and WASM in particular

flykespice 4y ago
Yet most of kotlin standard library is still functions extensions to Java package classes (jvm), if you filter out the function listing in the kotlin website to only implementations common across targets (Common tag), there is very little to be usable.
- brianslp 4y ago
  Due to the nature of being a frontend-for-everything I think it's best to keep the stdlib's platform-specific functionality minimal.
- tadfisher 4y ago
  Other platforms don't include Java's standard library, so it would be presumptuous to build one for each platform.
jillesvangurp 4y ago
It's increasingly a full stack language. I would say increasingly more so than javascript since it actually compiles down to native. So, you can use it in the browser, in the jvm, with node.js (not a great fit but it works), on edge networks or in lambda functions (with the native compiler or soon wasm), or on mobile devices. The main things holding kotlin native back have been the compiler and the library ecosystem. The compiler has been making a lot of progress over the last two years. And the library ecosystem has a growing number of high quality multi platform libraries. So, there's less need for wheel reinvention. Long term, given enough interest, it could start competing with Rust and Go for system programming type things. Right now, that's probably the weakest area for Kotlin but that is mostly because of the relatively immature library ecosystem around Kotlin native for this. IMHO the language actually fills a nice gap between Rust and Go. Easier than Rust, a bit more high level than Go. So far, Jetbrains seems more interested in mobile than in other use cases for kotlin native though. Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. There are some interesting libraries for Kotlin for this. But like with native this is all relatively immature and a bit niche at this point. Some interesting things you might not be aware off: - multi platform compose is a thing and as of recent releases it has an experimental IOS target as well. So, you can build desktop, android, web, and IOS capable applications now with using Kotlin. Unfortunately Desktop compose still depends on the JVM instead of using the native compiler. So, there's now a third alternative emerging next to Flutter and React Native for cross platform UI. - ktor server can now be used with the native compiler. So you now have two ways of producing native binaries for ktor via graal and the kotlin native compiler. Great for use with e.g. lambda functions as well. - kotlin scripting (KTS) is pretty nice and you can use it in more places than just Gradle. It works in Jupyter for example. Or you can generate github actions with it (we do this via krzema12/github-workflows-kt). - you can plugin wasm to kotlin (and lots of other languages) via extism.org. Haven't tried this but looks intriguing.
- dunefox 4y ago
  > Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. Julia and R are esoteric? For Data Science? Also, Kotlin would be relatively low on the list of languages I would use for DS. F# is higher.
  - jillesvangurp 4y ago
    For normal programmers I mean. I know lots of programmers. None of which specialize in Julia or R. They are specialist tools. Python is more a language for generalists. Which is why it is so popular in this space. Kotlin fits more in that category.

slim 4y ago

disappointed that gilles.deleuze.fr does not get you anywhere

rogue7 4y ago
My thought exactly when I saw the domain name
bouiaw 4y ago
Good one ^^. Sadly not from my family even if he is one of my prefered philosopher.
- slim 4y ago
  maybe redirect to webdeleuze.com :)

rektide 4y ago

> But WebAssembly becomes even more interesting when you take another perspective. What if Compose for Web, the multiplatform incarnation of Jetpack Compose used on Android, would leverage Kotlin/Wasm instead of Kotlin/JS to perform pixel-perfect Canvas based rendering? It would not really be very web like. It'd be more like Flash or a Java Applet. User extensions would all be broken. This is a new thing coming people. Now that we have wasm, the native-app folks are super jazzed about not only switching programming langauges, but getting rid of HTML and the DOM. The plan goes: we're replacing structure markup & hypertext of webapps with just-a-bunch-of-pixels, big canvases, that are purely computational constructs. Declarative information is getting blown up by imperative processes; this is how native apps are having their revenge against webapps. I have yet to see how any of this actually empowers or helps users: it seems like a huge downgrade, done purely to give developers alternative options. Maybe the experiences really are vastly better, maybe what we make is categorically different once we have this tech! But I really have a hard time (given what creativity we've had & seeing how quickly bootcamp folks come in & get hacking on the DOM) believing the DOM is really so horrible that it justified de-internet-izing the web & that turning it into a motion picture machine is warranted (as anything more than early exploration). The web starts with the HTML/DOM, and has been our computing world's greatest, most universal tower of Babel[1] that has held. I'm curious (and admittedly pretty terrified) to see who is happier/winners when we bring down the higher-level system, & treat it like a low level interface, like a big Canvas, like what was happening with Flash & Applets. Two other recent examples beyond Kotlin/Compose: Flutter/CanvasKit (which I commented on & got a reply from the lead about on these topics[2]), and Hixie's "Towards a Modern Web Stack"[3]. [1] https://unwindprotect.com/tower-of-babel https://unwindprotect.com/tower-of-babel https://news.ycombinator.com/item?id=34695638 https://news.ycombinator.com/item?id=34695638 [2] https://news.ycombinator.com/item?id=34527980 https://news.ycombinator.com/item?id=34527980 [3] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/preview?pli=1&resourcekey=0-bPajpoo9IBZpG__-uCBE6w https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696

ericmcer 4y ago
What does it really offer? Performance and flexibility? It will probably continue to be a niche for really specific high performance applications but the DOM will always exist as long as 99% of the internet is just viewing or uploading text/images/videos. The amount of experience and knowledge that has gone into fixing edge cases like accessibility, viewports, cross-browser support, security, etc. makes any kind of 'pure wasm' app a nightmare to maintain.

singularity2001 4y ago

Hello world is 1.5 MB but compiled surprisingly fast: less than a second (with grade running, couldn't test konanc -target wasm yet?) That's much better compilation time than kotlin/native:wasm Wasm types are currently inaccessible in JS and you can't feed js objects into wasm, hopefully that will change...

bouiaw 4y ago
Hello world with production artifact and Binaryen optimization produces a 128K Wasm file for now for https://github.com/vmware-labs/wasm-languages/tree/main/kotlin/browser-hello-world https://github.com/vmware-labs/wasm-languages/tree/main/kotl..., but the Kotlin/Wasm team has not tracked those data points recently so there are likely footprint regressions to fix. The size should be even smaller. They are going to have a look and also to enable Binaryen by default for production artifacts.
- singularity2001 4y ago
  nice + thanks

Existenceblinks 4y ago

Yes please, backend people (and compiler folks) be united to try to catch up with the latest wasm proposals, we are pretty close now (also waiting for the 'stringref'). The future is treating DOM stuff as system thingy, so we can stop (except those who want to stay) writing JS/TS on the logic part. I'm optimistic we will have a better mental heath on developing web frontend in near future.

dhalucario 4y ago

I don't know if anyone else had the idea yet, but I would love to use Kotlin with Svelte on the frontend.

Existenceblinks 4y ago
At some point someone will figure out the wire up between the reactive part (thing like "signal") on wasm side and and propagate changes to the effect side to render DOM nodes.
bouiaw 4y ago
I would love to see a Svelte-like frontend framework natively designed for Kotlin/Wasm, not necessarily another Kotlin to JavaScript binding that feels like a second class citizen.