Another <chasm> release! This time it comes with s...

# webassembly

[Charlie Tapping]

Another chasm release! This time it comes with support for the stable exception handling proposal 🎉 This allows languages like Kotlin to compile more naturally to webassembly and ultimately means smaller binaries. As @bashor mentioned if you want to enable these instructions in you rKotlin wasm compilations you need to put the following:

tasks.withType<KotlinJsCompile>().configureEach {
    compilerOptions {
        freeCompilerArgs.addAll("-Xwasm-use-new-exception-proposal")
    }
}

This release also hides the last of chasms internals from the public api, chasm’s error types now hold string representations of the internal error encodings, conveying the same information without leaking the types into the ABI.

Things will be quiet for the next month as I’m due to go travelling for 3 weeks but when I’m back I plan to continue stabilising the library ahead of a 1.0, implement the Threads proposal and … finally make some moves towards WASI (which is when this library really gets interesting 😁 )

[andylamax]

chasm always amazes me

[chrisjenx]

Sorry for stupid question, I understand it that you can run already built wasm code on KMM?

[Charlie Tapping]

A wasm runtime runs wasm programs, you can practically turn any language into a wasm binary now… meaning with chasm you can run any code from any language. But if we were to just focus on running Kotlin as an example, Chasm is an interpreter meaning it takes code and runs it directly on the cpu. This allows you to download Kotlin code (as a wasm binary) and run it dynamically. Potentially avoiding an app store release if you’re a mobile dev. Being KMP it also works on IOS and Web, you could write one module of code, in any language and dynamically update your client apps. This is just one of many use cases for a wasm runtime

[chrisjenx]

Oh that is very sneaky

[chrisjenx]

FYI, unless they changed it, I think the App Store has a no downloadable runtime code policy?

[Charlie Tapping]

They have guidelines around how to do it “safely” but it would never be prevented, a good percentage of apps now are cross platform, react native, xamarin etc. They are all ultimately interpreters as well, in a more abstract sense, any app is an interpreter, you conditionally render your ui depending on the response from the server. An interpreter is just a more broad abstraction of this same idea

[Charlie Tapping]

This isn’t a new idea btw theres libraries like this already https://github.com/cashapp/zipline

[chrisjenx]

Yeah it used to be more strict guess they had to ease the rules with crossplatform apps

[jw]

You aren't allowed to download executable binaries or dalvik bytecode. Interpreters have always been allowed on both platforms.

[chrisjenx]

Ah ok, that makes sense. I knew there was some form of restriction

[spierce7]

@Charlie Tapping Is chasm interpreting and running the wasm code in Kotlin Multiplatform, or are you delegating to existing wasm runtimes? I ask, because wouldn't Kotlin be slower at this than other languages?

I'd love to do an experiment to understand what the performance loss would be if we were to render Compose to a canvas on Android / iOS via wasm code. The end goal would be to live-ship updates outside of the app store of course. This becomes far more natural when you have more than just your data layer that can be dynamically updated.

[jw]

The problem with that, though, is you'd need to run synchronously on the UI thread.

[spierce7]

Interesting point. I wonder if that requirement could be circumvented via the NDK.

[jw]

You render to a GL context from non-main threads, but you'll still get input events on the main thread which will probably break some things (the ability to return true or false when an event was consumed or not, although maybe that only really matters for back/predictive back).

[Charlie Tapping]

@spierce7 Chasm interprets and executes directly, theres no handing off to anything else . In terms of Kotlin being slower than other languages as a language for the interpreter, I guess we’re talking about ones where you get more control over memory? Say C, Rust etc. Then yeah certainly I could make a much faster interpreter with one of those languages… But with Kotlin Multiplatform I have acceptable performance with a language I can use everywhere, JVM, Native etc.

I haven’t even began to optimise the interpreter yet but I have made some upfront decisions which are performance oriented. For example you’ll notice everything is a top level “static” function and no interfaces to prevent unnecessary dynamic dispatch. Theres a bunch of little things like this dotted throughout the implementation that attempt to minimise the languages runtime overhead.

I haven’t put much thought into rendering UI with chasm, though its absolutely possible with the help of host functions. I appreciate dynamic code delivery is likely most of the interest in the library but I’m personally looking forward to the using chasm to interact with libraries from other languages without having to go over an FFI. Once we have component model /WASI support, it should be possible to take any library from any language (which compiles to wasm) and interface with it. You can imagine with a bit of codegen you could actually have a Kotlin interface generated for you from the wasm file itself.

[spierce7]

Super interesting! I look forward to following the project!