Live data from Hacker News

WebAssembly Interface Types: Interoperate with All the Things

hacks.mozilla.org

61–70 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#61
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…

JavaScript is also "untrusted executable code". How is WASM any worse than JS?

Do you also advocate for removing ECMAScript lobbyists from standards bodies, and countering their promotion of JavaScript?

Re: WebAssembly Interface Types: Interoperate with All the Things

#62

Super happy to see WebAssembly Interface Types in development! At Wasmer (disclaimer, I'm the founder!) we've been creating integrations with a lot different languages (C, C++, Rust, Python, Ruby, PHP, C# and R) and we agree that this is a pain point and an important problem to solve. We're excited that Mozilla is also pushing this forward. If you want to start using WebAssembly anywhere: https://wasmer.io/ Keep up t…

Is this going to replace wasmer's WebAssembly interfaces?

As a library implementer, I'm a bit lost about how to expose functions from a wasm module to the outside world.

wasmer's interfaces have the advantage of being very simple to write. But they are not very expressive.

WebIDL is horrible, albeit more expressive.

At the same time, I feel like this is not enough.

My experience with libsodium.js, one of the first library exposing wasm (and previously asm.js) to other environments, has been that IDLs simply exposing function interfaces are not good enough.

For example, C functions returning 0 or -1 to indicate an error or not, would not be idiomatic at all if exposed that way in Scala, Javascript or Python. We want these to raise an exception instead.

Also, we need ways to preallocate buffers, check their size, etc. in order to make things appear more idiomatic.

In libsodium.js, the description language for the WebAssembly JS glue is JSON-based. It describes the input and output types, but also their constraints, and how to interpret the output. That was necessary, and if more languages are targeted, this is even more necessary.

I feel like WebIDL is both complex, and insufficient.

Another thing that I don't necessarily get is why such a description language was designed specifically for WebAssembly.

Instead, we could have (yet another) way to describe APIs and how to encode that description. That description can then be included in ELF libraries, in Java objects, in WebAssembly modules, whatever. You know, like, what debuggers already use.

Re: WebAssembly Interface Types: Interoperate with All the Things

#63
post #18

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…

I'm a full time React developer but I would much rather see the CLR than WASM as a universal platform target.

The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming.

It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellisense are pretty good as well.

It has good packaging support with assemblies. And you can already compile .NET code to WASM using Blazor.

And with .NET already running on Linux, Win, Mac, iOS, Android, and IOT devices, I don't really see targeting WASM adding anything that doesn't already exist.

Re: WebAssembly Interface Types: Interoperate with All the Things

#65
post #63
post #18

Earlier 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'm a full time React developer but I would much rather see the CLR than WASM as a universal platform target. The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming. It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellis…

[deleted]

Re: WebAssembly Interface Types: Interoperate with All the Things

#66
post #34

Earlier quoted context omitted.

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.

This probably a good subject for a separate thread, but I do wonder why JVM-in-browser failed so hard. I know there were "security issues" but surely those weren't any worse than the JS security issues we have today?

Steve Klabnik wrote a blog post around this last year. More challenging the "isn't WASM just another Java?" take, but I think still relevant to your question.

https://words.steveklabnik.com/is-webassembly-the-return-of-...

Re: WebAssembly Interface Types: Interoperate with All the Things

#67
post #60

Side comment: a Thumbs-up for Lin Clark and her usual Mozilla blog posts including this one. It is easy to understand, very informative and the hand-drawn infographies makes it pleasant to read.

Would also like to add that the video in the article (https://www.youtube.com/watch?v=Qn_4F3foB3Q) is really well made and to the point

Re: WebAssembly Interface Types: Interoperate with All the Things

#68

Glad to see this being worked on. The difference between a heap vs. runtime managed object is a huge perf gap for tightly interoperating JS and WASM. At my company, we built a specific object representation that would allow zero copy, through array buffer sharing, views of C++ data from Javascript. Sounds very similar to this.

I got the impression from the article that it will always copy data (e.g. strings) between wasm modules. Did I misread it?

Re: WebAssembly Interface Types: Interoperate with All the Things

#69
post #35

Earlier quoted context omitted.

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.

As far as I know, WASM was thought of as a compilation target for languages like C and Rust, which are quite different from Java and C#.

That alone should make WASM quite different from the JVM, no?

Re: WebAssembly Interface Types: Interoperate with All the Things

#70
post #63
post #18

Earlier 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'm a full time React developer but I would much rather see the CLR than WASM as a universal platform target. The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming. It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellis…

Yes but like the parent poster said, all of the CLR features are really to serve one language: C#. All other languages primarily targeting the CLR must be understood in the context of “how would you express this thing in C# and how will a C# client interact with your assembly”.

Thus, WASM will forever be tied to javascript and all other languages will need to deal with questions of “how would I express this in JavaScript”.

Post reply on HN