Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Interface Types: Interoperate with All the Things

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#41

Post by baybal2 »

I'm a strong opponent of WASM because I think that WASM will break the internet the very same way and same reason ActiveX and Java applets broke it over 20 years ago.

An untrusted executable code, no matter how much sandboxed, virtualised, and isolated it is, would never be a good thing. It wasn't 20 years ago, and would never be, invariably of what "tech sauce" it is served with.

I advocate for proactive removal of WASM lobbyists from standard setting bodies, and countering their promotion of WASM.

Re: WebAssembly Interface Types: Interoperate with All the Things

#42

Post by ori_b »

cesarb wrote: post #40
ori_b wrote: post #33

Earlier quoted context omitted.

> 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.

So, the solution is to make more or less every foreign call unsafe. That's pretty close to the state of the art without wasm.

I'm not sure how satisfactory that is, especially when it is fairly idiomatic for many calls in garbage collected languages to both keep and return a reference (eg, builder pattern), which may lead to rust calling a destructor where the other language doesn't expect it.

Re: WebAssembly Interface Types: Interoperate with All the Things

#43

Post by icebraining »

the8472 wrote: post #37
asdkhadsj wrote: post #23

Earlier quoted context omitted.

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.

If you're distributing an executable (not a library), you can just AOT compile the generated wasm to machine code.

For example, the WasmExplorer already lets you compile C++ -> wasm -> x86 assembly: https://mbebenita.github.io/WasmExplorer/?state=%7B%22option...

Re: WebAssembly Interface Types: Interoperate with All the Things

#44

Post by omn1 »

baybal2 wrote: post #41

I'm a strong opponent of WASM because I think that WASM will break the internet the very same way and same reason ActiveX and Java applets broke it over 20 years ago. An untrusted executable code, no matter how much sandboxed, virtualised, and isolated it is, would never be a good thing. It wasn't 20 years ago, and would never be, invariably of what "tech sauce" it is served with. I advocate for proactive removal of…

ActiveX and Java applets were proprietary when they got introduced. WASM is an open standard that it supported by all browser vendors and already integrated without any third-party plugins. There is a spec for it that you can contribute to.

Re: WebAssembly Interface Types: Interoperate with All the Things

#45

Post by baybal2 »

omn1 wrote: post #44
baybal2 wrote: post #41

I'm a strong opponent of WASM because I think that WASM will break the internet the very same way and same reason ActiveX and Java applets broke it over 20 years ago. An untrusted executable code, no matter how much sandboxed, virtualised, and isolated it is, would never be a good thing. It wasn't 20 years ago, and would never be, invariably of what "tech sauce" it is served with. I advocate for proactive removal of…

ActiveX and Java applets were proprietary when they got introduced. WASM is an open standard that it supported by all browser vendors and already integrated without any third-party plugins. There is a spec for it that you can contribute to.

It doesn't change a thing. Both ax and java were quite well documented and free for everybody to use, but they definitely broke the Internet for everybody without any exaggeration.

I'll explain you why in the most neutral tone I can.

Do you understand that biggest peddlers of inscrutinable executable format on the web are people who are not fine with the open nature of the Internet, and who can not make their business when all code available through the browser is available to at least minimal form of inspection?

In other words, the people who are mad because they can't run business in the web because their business model depends on their code being closed, they WANT THIS big time. Their business thrives off non-interoperability and brokennes of software at large. Their success comes at the detriment of the Internet ecosystem at large. The more they brake the Internet for the rest of its users, the more money they can make, and this is why there can not be reconciliation with them and, us, the wider and more sane part of software developer community.

And we, the engineering cadres, the most influential class of people in the new tech driven world, have all the influence needed to deny WASM adoption.

Re: WebAssembly Interface Types: Interoperate with All the Things

#46

Post by icebraining »

pjmlp wrote: post #28
vcarl wrote: post #16

Earlier 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/

I looked into their WebAssembly demo, but it doesn't seem to use WebGL, just a regular DOM (with an ungodly number of elements).

Re: WebAssembly Interface Types: Interoperate with All the Things

#47

Post by kodablah »

wahern wrote: post #18
the_duke wrote: post #13

I'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…

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…

> At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc

I agree with the latter two due to runtime uniqueness, but not so sure it holds for Rust. Since C FFI has become the defacto WASM standard (with higher level interop coming as the article suggests), some low-overhead langs like Rust can be reasonably used elsewhere via WASM (though in most cases, you'd use them as native libs if you had the option).

Essentially it comes down to two things: How much of the WASM conformance is language-specific at compile time (e.g. for Go, stack resumption is manually built causing bloated WASM), and how much overhead does WASM interop cause at runtime (e.g. can it use the string interface type instead of converting to what it considers a string in local memory and what are the tradeoffs of each approach). If your language has a low WASM impedance mismatch at compile time and runtime, like Rust, it is a decent candidate for a WASM target. If your runtime has a low WASM impedance mismatch (e.g. the browser, native, and to some extent the JVM), it is a decent candidate to run that other decent-candidate WASM code without a huge overhead.

I've run Rust on the JVM [0], C in the browser, etc with decent performance because of those characteristics.

0 - https://github.com/cretz/asmble/tree/master/examples/rust-re...

Re: WebAssembly Interface Types: Interoperate with All the Things

#48

Post by the_duke »

cesarb wrote: post #40
ori_b wrote: post #33

Earlier quoted context omitted.

> 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.

If I understand the proposal correctly, it should actually be possible to auto-generate safe glue code.

These interface types can describe, eg, how to map a Python String or list to a generic representation (pointer + length), and Rust can then take this generic form and map it into a valid Rust string safely - with the intermediate guarantees verified by the WASM runtime.

Re: WebAssembly Interface Types: Interoperate with All the Things

#49

Post by AlexanderDhoore »

baybal2 wrote: post #45
omn1 wrote: post #44

Earlier quoted context omitted.

ActiveX and Java applets were proprietary when they got introduced. WASM is an open standard that it supported by all browser vendors and already integrated without any third-party plugins. There is a spec for it that you can contribute to.

It doesn't change a thing. Both ax and java were quite well documented and free for everybody to use, but they definitely broke the Internet for everybody without any exaggeration. I'll explain you why in the most neutral tone I can. Do you understand that biggest peddlers of inscrutinable executable format on the web are people who are not fine with the open nature of the Internet, and who can not make their busines…

Modern minified javascript is just as inscrutable as anything else.

For example, please try to read this code: https://apis.google.com/js/client.js

You would need a "decompiler" to make anything out of that.

Re: WebAssembly Interface Types: Interoperate with All the Things

#50

Post by thesuperbigfrog »

Rusky wrote: post #35
pjmlp wrote: post #32

Earlier quoted context omitted.

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.

Would you please share the "very specific technical differences"?

As a long-time JVM user, I am curious about WASM and how it compares to the JVM and CLR.

Post reply on HN