Да до сих пор баги имеются. Вообще это очень странно, так как Wasm и JS шарят по сути один и тот же кодогенератор.

Но и баги зачастую там не с этим связаны

what do you think about this kind of interoperability?

I have implemented something similar but I'm not sure how effective it can be

for example, plugin python scripts into a NodeJS express server: https://medium.com/@metacall/this-scraping-serverless-polyglot-is-metacall-c13223ae1cb5

this can be done with C/C++ servers as well, like Envoy, NginX..

Кто-нибудь уже пользовался Wasm в Envoy + Istio? Я смотрю там можно из васма делать хттп вызовы, это правда?

https://github.com/solo-io/proxy-runtime/blob/dfe0301da3517361b1e20b6f7419cb7a46a641be/assembly/runtime.ts#L804

Насколько я помню, таки разделение кодегенов есть

Ну у JSC как раз таки возможно

всем привет, извините за оффтоп, пытаюсь вести свой канал с подборками различных open-source решений (wasm в частности) https://t.me/opensourcefuture, кому интересно - welcome)

И в уже неиспользуемом чакракоре тоже

там саму систему ломали пару раз, чё уж за васм говорить

Чтоб быстрее сделать первую версию. Постепенно будут добвалять много новых типов.

Какие в первую очередь?

SIMD, anyref, exnref, funcref

дальше struct и array

Где-то читал что и string хотели сделать

интересненько

Делать строковый тип нецелесообразно. Так как есть куча форматов кодировки: ASCII, UTF7, UTF8, WTF8, UTF16LE, USC2, UTF16BE, WTF16, BOM, UTF32LE, UTF32BE, UTF-EBCDIC, LMBCS и т д. И если вы думаете что можно отделаться только одним UTF8 то спешу вас разочаровать - нет! Более того для общения с тем же веб апи и файловой системой Windows придется еще хотя бы UTF16 или WTF-8. Еще wasm будет делать интероп с другими языками в будующем, а там вообще солянка. Так что жестко привязываться к какому то типу строки - это только усложнить себе и другим жизнь

BOM - это же не кодировка? 😊