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

21–30 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#21

Post by k__ »

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…

Could it be that JVM and CLR were technically correct, but policy wrong?

Re: WebAssembly Interface Types: Interoperate with All the Things

#22

Post by RussianCow »

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…

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.

Re: WebAssembly Interface Types: Interoperate with All the Things

#23

Post by asdkhadsj »

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…

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?

But you're right, maybe this will go the way of the JVM and no one will care. Or maybe not. Does it matter?

edit: And I should add, maybe I keep forgetting where my well supported JVM Python Rust or Go Rust bridge is. Maybe someone can remind me, because I've not seen it.

Re: WebAssembly Interface Types: Interoperate with All the Things

#25

Post by wahern »

asdkhadsj wrote: post #23
wahern wrote: 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…

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…

I don't doubt that the ubiquity of WASM environments will result in more software targeting the environment. My contention is with the notion that we'll all be seamlessly mixing different languages.

Far more likely is that WASM influences the evolution of various languages, resulting in homogenization of semantics. C++ is already going in this direction--preferring some proposals over others because of easier interoperability with WASM's constraints. Other languages with irreconcilably distinct semantics, such as Go's goroutines, are likely doomed to be second-class citizens as compared to Rust or C++. Languages like Python and PHP are likely to see either major refactoring of their engines, or else see the rise of alternative implementations that are more performant in WASM environments and offer more seamless data interchange.

Re: WebAssembly Interface Types: Interoperate with All the Things

#26

Post by sunfish »

asdkhadsj wrote: post #23
wahern wrote: 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…

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…

It's a balance. You probably won't see things like Rust's `Vec` exposed as a wasm API by itself, because at that granularity, language-speciric API details are really important, and the actual code you could reuse is relatively small. But at larger scopes, the advantages of mixing languages and introducing sandboxing become more interesting in the balance.

Re: WebAssembly Interface Types: Interoperate with All the Things

#28

Post by pjmlp »

vcarl wrote: post #16
asdkhadsj wrote: post #11

Earlier quoted context omitted.

> but there's not really a substantive benefit to writing your entire app with it. Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that. So while the concrete performance boost may not be meaningful in writing a…

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/

Re: WebAssembly Interface Types: Interoperate with All the Things

#29

Post by sunfish »

_khhm wrote: post #24

WOW that was too much to read. Can someone TLDR when we'll be able to get rid of Electron using this for me?

Much of what makes Electron Electron are the APIs it provides. The blog post here is a way to describe and work with APIs, not actual new APIs.

We're working on APIs too, in WASI, but there's a lot of work to do to build everything you'd need to build Electron-like apps.

Re: WebAssembly Interface Types: Interoperate with All the Things

#30

Post by pjmlp »

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…

You mean like I would use IronPython, with the codecs coded in C++/CLI, ML analysis in F# and the UI in XAML/C# all on top of the CLR?
Post reply on HN