Hey team, is there a roadmap for the new Kotlin/Wa...
# webassembly
k
Hey team, is there a roadmap for the new Kotlin/Wasm compiler backend, or is just a case of “it will be ready one day”?
b
It's waiting for wasm gc mainly
👆 2
k
Ah that makes sense, thanks for the speedy reply. Is there a way to use the deprecated wasm32 target from Konan outside of a browser context or is it reliant on the arena allocation methods etc from the engine?
for example, if i wanted to run a kotlin app in wasmtime: https://github.com/bytecodealliance/wasmtime
b
No clue, I've only used it in browser scenario
d
@kailan you can follow this issue: https://youtrack.jetbrains.com/issue/KT-42292
k
fantastic! thank you
My team seem to be under the impression that Wasm GC is years out from being usable…. is this commonly known?
b
@kailan with new compiler backend we mostly are focused on browser usecases, one of reason is that we don’t see much interest from standalone VM vendors to new GC proposal. We would happy to change it and collaborate with standalone VM vendors too.
Another, point is that at some point somebody can create convertor from
Wasm with GC
to
Wasm without GC
which allow us an other projects simply run even on VMs w/o GC proposal support.
Implementation in Kotlin/Native is self contained and use own memory manager, produced binary theoretically could be run inside any Wasm MVP VM. But NOTE: we are going to deprecate and remove it in the foreseeable future.
In near future we’ll update the related roadmap issue, stay tuned!
👍 2
e
Forgive me for my ignorance, my knowledge isn’t anywhere near sufficient enough to realize the magnitude of work needed for the following question; Couldn’t the (new) Kotlin/native memory model be reused in Kotlin/Wasm until the official GC is implemented? (https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/) I understand shipping a garbage collector to each users’ browser is far from ideal size and performance wise, but couldn’t it boost Kotlin/Wasms development?
b
The team decided to prioritize other things rather than chasing current LLVM based KWASM that's already deprecated. Given the colossus that kotlin multiplatform is, seems like a sensible decission if you ask me.
Also I wouldn't expect new K/N memory model until 1.6 at the earliest