WebAssembly Interface Types: Interoperate with All the Things • Hacker News Board

Re: WebAssembly Interface Types: Interoperate with All the Things

#101

Post by throwaway34241 » Thu, Aug 22, 2019, 7:04 AM UTC

ori_b wrote: post #36

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? 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…

I've often wondered for client-side apps if a simple thread-per-goroutine model would work for Go. Sure, you'd lose some of the easy scalability. But I think that's mostly useful for server software and client apps don't usually have thousands of concurrent tasks anyway. You could also lower the overhead some for calling C libraries (which client software does more often).

Re: WebAssembly Interface Types: Interoperate with All the Things

#102

Post by coldtea » Thu, Aug 22, 2019, 7:11 AM UTC

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…

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

Java tied a whole ecosystem and was a pain to connect to anything outside, Parrot is a perennially incomplete half-arsed experiment, and C# has been historically tied to the MS ecosystem (and is also a pain to link to from outside).

The promise here is that the new system would have cross platform, cross vendor support (e.g. MS, Apple, Google, Mozilla), and that it wont be a pain to link to from, say, C or Rust or Python.

>WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did.

Doesn't need to. It's enough that it solves the same issue linking to a C library with bindings does, but without re-compilation, with a sandbox, and an easier interface.

I'd like to use e.g. something like Pillow or a numeric lib, etc, in WASM from languages outside Python...

Re: WebAssembly Interface Types: Interoperate with All the Things

#103

Post by 6gvONxR4sf7o » Thu, Aug 22, 2019, 7:24 AM UTC

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…

The very first sentence in the article is

>People are excited about running WebAssembly outside the browser.

This article isn't about the internet. Read through it with a mindset of webassembly outside of web. It's an interesting article.

Re: WebAssembly Interface Types: Interoperate with All the Things

#104

Post by miguelrochefort » Thu, Aug 22, 2019, 7:28 AM UTC

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/

Uno uses DOM bindings, not WebGL.

Re: WebAssembly Interface Types: Interoperate with All the Things

#105

Post by kevingadd » Thu, Aug 22, 2019, 8:00 AM UTC

CUViper wrote: post #86

mkl wrote: post #85

> Document.createElement() takes a string. But when I call it, I’m going to pass you two integers. Use these to create a DOMString from data in my linear memory. Use the first integer as the starting address of the string and the second as the length. This seems like its introducing buffer overflow vulnerabilities, if the code can be tricked into using the wrong numbers. Sure, just into WebAssembly memory, but if eve…

Doesn't each wasm module get its own isolated memory? If so, then you could only shoot your own sensitive foot.

Yes, but a "module" can be an application and a full set of its dependencies. It's unlikely that its dependencies would have isolated heaps, as there would be no way for them to communicate (they can't touch each others' pointers, etc) other than through intermediary JS.

So any vulnerability in any piece of wasm in your webpage effectively compromises everything. One compromised module can also likely reach out into the page and then use other modules' public interfaces to compromise them too. There is not sandboxing in place to prevent this sort of attack, the sandbox merely protects the browser from attack by content.

Re: WebAssembly Interface Types: Interoperate with All the Things

#106

Post by chrisseaton » Thu, Aug 22, 2019, 8:29 AM UTC

afiori wrote: post #96

chrisseaton wrote: post #81

Earlier quoted context omitted.

I didn't claim it was a good binary format - I just claimed GraalVM supports it, which it does.

But it is not an application delivery format which is the whole point here.

I ship LLVM to deliver applications just fine.

Re: WebAssembly Interface Types: Interoperate with All the Things

#107

Post by erlend_sh » Thu, Aug 22, 2019, 8:34 AM UTC

syrusakbary wrote: post #12

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…

We are exploring using Wasmer as a scripting/modding platform in the Amethyst game engine: https://github.com/amethyst/amethyst/pull/1892

Re: WebAssembly Interface Types: Interoperate with All the Things

#108

Post by repolfx » Thu, Aug 22, 2019, 8:53 AM UTC

nerdponx wrote: post #56

mrec wrote: 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?

It didn't fail that hard. It was pretty widely used, but the JRE was a large and not very fast runtime back then. It got better over time but the browser makers got pretty determined to kill off any competing platforms to HTML under the guise of security.

Re: WebAssembly Interface Types: Interoperate with All the Things

#109

Post by repolfx » Thu, Aug 22, 2019, 9:00 AM UTC

Rusky wrote: post #80

chrisseaton wrote: post #79

Earlier quoted context omitted.

> Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs It does - LLVM bitcode.

LLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers. Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it work by strictly controlling the target hardware they use it for, and with massive investment in the toolchain.

That's more a criticism of C rather than LLVM. Bitcode isn't as portable or stable as JVM bytecode because real world C programs use processor specific intrinsics, make assumptions about endianness and word sizes, embed assembly etc etc. LLVM is designed to support all real C programs, which means it can't be entirely portable.

Wasm today is a toy hardly anyone uses. It can't run many real world C programs which means they'll need to be "ported" to the subset of C wasm supports. Well, if you're willing to work with that constraint you can constrain bitcode in the same way.

By the way Graals LLVM support can execute multiple bitcode versions, with seamless and fast language interop, and it virtualises execution so that e.g. a subset of x86 assembly can be cross compiled on the fly to other arch's. It's needed because so much real C doesn't target an abstract machine but real CPUs.

Re: WebAssembly Interface Types: Interoperate with All the Things

#110

Post by flohofwoe » Thu, Aug 22, 2019, 10:19 AM UTC

pjmlp wrote: post #97

flohofwoe wrote: post #74

Earlier quoted context omitted.

The simple C-style linear memory model is the most important one IMHO, since this preserves the explicit control over the entire memory layout of an application which languages like C, C++ or Rust allow. Optimizations for efficient use of CPU caches carry over into WASM. AFAIK both CLR and JVM use a much higher level model which is built around fine-grained allocations managed by a GC.

CLR supports C++ since version 1.0. In fact it had two versions of it, Managed C++ released in version 1.0, replaced by C++/CLI with version 2.0. JVM has support for C-style linear memory model on its unsafe interfaces (the non-public ones), and is being improved via Graal (which understands LLVM bitcode) and Projects Panama/Valhalla.

Ah alright, thanks for the clarification. Pre-WASM emscripten actually shows that it's possible to compile C to any language or virtual machine that has simple linear arrays to use as C's heap, it's just not as efficient.