[deleted]
WebAssembly Interface Types: Interoperate with All the Things
31–40 of 119 posts
Re: WebAssembly Interface Types: Interoperate with All the Things
#32Earlier quoted context omitted.
JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they d…
Could it be that JVM and CLR were technically correct, but policy wrong?
It is more politics than anything else, with WASM being the new cool kid on the block.
Re: WebAssembly Interface Types: Interoperate with All the Things
#33I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compat…
> Webassembly really could enable seamless cross-language integration in the future.
> Writing a project in Rust, but really want to use that popular face detector written in Python?
So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python, and transparently forward calls to the bound __call__ method of python objects?
The calls are easy, even today. Semantics are hard.
Re: WebAssembly Interface Types: Interoperate with All the Things
#34Earlier quoted context omitted.
JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they d…
I mostly agree with you, but it's important to point out that the big difference between WASM and the runtimes you mentioned is that WASM works in the browser, so you get out-of-the-box support for the world's biggest app platform. That's something that no other cross-platform runtime has achieved in any meaningful way, as far as I know.
Java used to work in the browser a quarter-century ago, albeit not very well. Even .NET sort of worked in the browser for both the people who enabled Silverlight.
I do believe WASM is different, in a good way, but not just because it works in a browser.
Re: WebAssembly Interface Types: Interoperate with All the Things
#35Earlier quoted context omitted.
Could it be that JVM and CLR were technically correct, but policy wrong?
It is more politics than anything else, with WASM being the new cool kid on the block.
You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.
Re: WebAssembly Interface Types: Interoperate with All the Things
#36Earlier quoted context omitted.
JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they d…
Ah, there it is, the JVM discussion in any WASM thread. I kid. On topic though, I'll be curious to see how bad it really is. The demo video showed code that ended up looking and behaving like normal Rust code. Maybe you'll end up with some oddities like Rust enums not being supported, but w/e. At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win? B…
> At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win?
You just need to manually insert stack growth checks before all function calls in anything that can be called from go to support goroutines, because those can't live on a normal stack and still be sufficiently small to support desired go semantics. Async has similar issues, where the semantics are incompatible, which means that many things go horribly wrong in cross-language calls
Or you use a lowest common denominator and essentially treat the thing like an rpc, with a thick layer to paper over semantic mismatches.
And that's before we get to things like C++ or D templates, Rust or Lisp macros, and similar. Those are lazy syntactic transformations on source code, and are meaningless across languages. Not to mention that, if unused, they produce no data to import. But, especially in modern C++, they're incredibly important.
Re: WebAssembly Interface Types: Interoperate with All the Things
#37Earlier quoted context omitted.
JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they d…
Ah, there it is, the JVM discussion in any WASM thread. I kid. On topic though, I'll be curious to see how bad it really is. The demo video showed code that ended up looking and behaving like normal Rust code. Maybe you'll end up with some oddities like Rust enums not being supported, but w/e. At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win? B…
> At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win?
That stuff only works if you limit yourself to exclusively run in a wasm runtime. If you want to compile to any other platform you still need C glue code.
Re: WebAssembly Interface Types: Interoperate with All the Things
#38Earlier quoted context omitted.
Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.
DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/
For a smallish subset of use cases, maybe. But replacing the DOM with a canvas-based UI for general use would be reinventing many of the problems of Flash.
Re: WebAssembly Interface Types: Interoperate with All the Things
#39Earlier quoted context omitted.
Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.
DOM bindings are kind of irrelevant when one has WebGL. One example among many ramping up https://platform.uno/
Rendering UIs in webgl is fairly user-hostile. No accessability, no extensions, no custom styles, ...
Re: WebAssembly Interface Types: Interoperate with All the Things
#40I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compat…
> Webassembly really could enable seamless cross-language integration in the future. > Writing a project in Rust, but really want to use that popular face detector written in Python? So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python, and transparently forward calls to the bound __call__ method of python objects? The calls are easy, even today. Semantics are hard.
> So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python
In Rust, calling foreign functions is considered unsafe, precisely for that reason: once you leave the boundaries of a single language, the compiler can no longer enforce these invariants for you.