Any take on this from a Kotlin perspective ? <http...

# webassembly

[sdeleuze]

Any take on this from a Kotlin perspective ? https://twitter.com/assemblyscript/status/1419110937261449216?s=21

[napperley]

The main takeaway from this announcement is that Kotlin WASM needs to develop its own ecosystem, and not rely heavily on JS interop, which may not be guaranteed with the WASM platform.

[napperley]

It may be very likely that JS libraries can't be used on WASM anyway. I hope that Kotlin WASM doesn't have a heavy reliance on JS like AssemblyScript does 🙏, otherwise there would be no point in developing Kotlin WASM further.

[napperley]

With WASM there would need to be some standard way to support strings in some form (obviously NOT in JS form) with its ABI. Many APIs use strings, and no string support would severely hamper WASM's usability as a platform.

[napperley]

If you look at Kotlin Native with the Linux platform for example, Kotlin accesses strings from the C side via CPointer<ByteVar>? , and converts the fake C string to a real Kotlin string via the toKString function (the main way to do it). Something similar would need to be in place with the WASM platform.

[napperley]

In the worst case scenario Kotlin WASM may need to have interop with the C++, and Rust programming languages in order to access third party WASM APIs.

[altavir]

I agree about independent ecosystem. Kotlin stdlib and kotlinx already rival most of JS ecosystem (save for styling frameworks like bootstrap). In my experience, the most struggle with JS ecosystem is quality of those libraries, and I do not see problems with doin things from scratch on kotlin.

[sdeleuze]

Thanks for sharing your thoughts

[Svyatoslav Kuzmich [JB]]

Notice seems to be lacking some context. What are the “unresolvable correctness and security problems”? Is it about not being able send arbitrary binary data, possibly invalid Unicode, via string type of Interface Types proposal?

[sdeleuze]

I think

https://youtu.be/Ri2NMnSQo4o▾

is related if you want more context.

[sdeleuze]

If UTF-8 is chosen for Wasm String early august, will Kotlin/Wasm use that natively?

[sdeleuze]

I am not too puzzled by the JS interrop, but I am wondering if that could be an issue for Kotlin or JVM worlds.

[sdeleuze]

See also https://twitter.com/tlively52/status/1419409488529043458?s=21

[Svyatoslav Kuzmich [JB]]

If UTF-8 is chosen for Wasm String early august, will Kotlin/Wasm use that natively?

We would want to still use WTF-16 for multiplatform consistency.
But I doubt that UTF-8 would be chosen as the only encoding for browser API and JS interop, because JS and DOM strings are WTF-16 and many languages with matching encoding would want to pass strings back and forth without double conversion.

[sdeleuze]

Ok so I guess we will have to define the boundaries of what is exposed like @JsExport , maybe via something like @WasmExport?

[sdeleuze]

I guess the AssemblyScript team is puzzled because they had full compat until now via custom binding generation and the standardization of Wasm string will force them to identify what is exposed and what is not ...

[Svyatoslav Kuzmich [JB]]

I hope that Wasm would expose some low-overhead access to JS strings from inside Wasm. We could use these as Kotlin/Wasm string and avoid copy at the boundary.

[sdeleuze]

Ok I see

[sdeleuze]

Maybe worth to check with Google is that's the plan before the vote August 3rd.

[sdeleuze]

That would be useful for a lot of languages

[Svyatoslav Kuzmich [JB]]

Just for the context, the poll will be about https://github.com/WebAssembly/interface-types/issues/135

[sdeleuze]

Interesting thanks for sharing. Glad Luke Wagner is leading this, I have a deep respect for his work.

[sdeleuze]

Another advice on this https://news.ycombinator.com/item?id=27953440.

[napperley]

There is no guarantee that WASM will allow access to JS/DOM APIs. I agree with Alexander Nozik that Kotlin would be fine on having APIs built from scratch. It is looking increasingly likely that WASM will be a black canvas, and that custom Kotlin APIs will be required to provide the foundations. This could be the first Kotlin development platform in history that heavily relies on Kotlin APIs unlike the other Kotlin development platforms (Kotlin JVM, Kotlin Native etc).

[Svyatoslav Kuzmich [JB]]

JS/DOM APIs are already available in Wasm. The main problem is that browser APIs are routed through JS, which is suboptimal given that both sides are statically typed. Interface Types is promised to be a solution to this in the future.