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

111–119 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#111

Post by pjmlp »

repolfx wrote: post #109
Rusky wrote: post #80

Earlier quoted context omitted.

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

Actually LLVM Bitcode can be made portable, that is what Apple does in their store apps for watchOS.

Re: WebAssembly Interface Types: Interoperate with All the Things

#112

Post by aloknnikhil »

Good effort. But the bit about using Protobuf, Cap'nProto only in processes that don't share memory is wrong. Sure, that may not be how they're traditionally used. But that doesn't exclude me from defining opaque C FFIs that pass/return opaque bytes that are serialized messages and have it be deserialized on the other end.

Re: WebAssembly Interface Types: Interoperate with All the Things

#113

Post by Rusky »

pjmlp wrote: post #94
Rusky wrote: post #78

Earlier quoted context omitted.

WebGL bindings are on the same footing as DOM bindings- they're not an alternative in this sense, because insofar as we have one we already have the other.

No because accessing WebGL contexts directly from WebAssembly, specially WebGPU ones, is something that keeps coming up in some Chrome presentations. And thanks to many, including HN readership, Chrome and Safari are the only browsers that many businesses care about nowadays.

What I'm saying is, the feature/mechanism that lets WebAssembly call WebGL or WebGPU is exactly the same one that lets it call DOM APIs. The same implementation work supports both.

Re: WebAssembly Interface Types: Interoperate with All the Things

#114

Post by Rusky »

pjmlp wrote: post #92
Rusky wrote: post #75

Earlier quoted context omitted.

Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source. The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode-…

Besides chrisseaton's answer, not only is C++/CLI already compatible with C++17, it will be part of .NET Core Windows variant, because it was yet another reason why we wouldn't migrate away from .NET Framework. WASM in its current form is still quite limited forcing language runtimes to bring along features that other battlefield proven solutions support out of the box. Hardly a synonym for unmodified .

C++/CLI is already full of incompatibilities with C++17 (and C++14, and C++11), and there are plans to cut off C++/CLI support with newer standards. Existing support is mostly by accident.

Meanwhile "must distribute a runtime with the app" does not affect the language at all, and indeed applies to these other solutions as well.

Re: WebAssembly Interface Types: Interoperate with All the Things

#115

Post by wahern »

marcosdumay wrote: post #77
wahern wrote: post #25

Earlier quoted context omitted.

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

Goroutines only require a slightly fat runtime. Haskell uses basically the same mechanism, with C interoperability, and all it takes is starting (and optionally, stopping) the runtime.

It's not having a runtime that's the problem, it's limitations in WASM's control flow constructs: https://github.com/WebAssembly/design/issues/796#issuecommen...

And WASM has this limitation as a consequence of limitations in the V8 and SpiderMonkey engines. See http://troubles.md/posts/why-do-we-need-the-relooper-algorit... and https://news.ycombinator.com/item?id=19997091 And those engines have those limitations because they're a reasonable design tradeoff in the context of executing JavaScript.

I think even if WASM gets a limited goto sufficient to resolve the most problematic performance issues, languages like Go that use more sophisticated control flow constructs (e.g. stackful coroutines) will always be at a disadvantage relative to C or Rust when it comes to WASM as absence of other various low-level constructs (e.g. ability to directly handle page faults) will incur higher relative penalties. The same thing could be said about Rust's new async/await--WASM will compound the costs of the additional indirect branching in async-compiled functions (not to mention the greater number of function invocations, which is at least 2x even if a function never defers).

That said, I don't think anybody uses Go for the insane performance, so as long as the performance impact isn't too severe (and limited goto support will help tremendously) it shouldn't be much of an issue. OTOH, these sorts of tradeoffs are why "native" code will always have a significant place. Especially as the wall we've hit in terms of single-threaded performance begins to be felt more widely.

Re: WebAssembly Interface Types: Interoperate with All the Things

#116

Post by yellowapple »

pjmlp wrote: post #93
yellowapple wrote: post #87

Earlier quoted context omitted.

WASM is much smaller and simpler than either. This makes it easier to implement, both within browsers (as evidenced by most mainstream browsers already supporting it natively, and the rest via a polyfill) and beyond (e.g. the myriad of WASM runtimes out there - both interpreted and JIT/AOT compiled - written in all sorts of languages and usable outside a web browser). Same goes for most other bytecode VMs of a simila…

WASM MVP is smaller and simpler. The WASM that everyone dreams about will be the same size, if it is supposed to match in features. Plenty of bytecode formats since have been AOT/JIT since the early 70's. We wouldn't even be discussing WASM if Mozilla wasn't unwilling to implement PNaCL. Apparently being open source, with initial support for C, C++ and OCaml support wasn't enough.

> The WASM that everyone dreams about will be the same size, if it is supposed to match in features.

The WASM I dream about (can't speak for anyone else) won't be a whole lot bigger than it is now [0], and I don't think anyone expects it to match the bigger VMs in features (the sheer number of features in the bigger VMs is part of the problem!).

----

[0]: It's already pretty great, IMO, and the additions I'd like to see - namely, support for multiple memories, and the handful of extra instructions necessary to support tail call optimization [0.1] and garbage collection [0.2] - ain't expected to be that huge of an addition in terms of instruction set bloat. I'm hopeful that they won't be especially complex to implement, either.

[0.1]: https://github.com/WebAssembly/tail-call/blob/master/proposa...

[0.2]: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

Re: WebAssembly Interface Types: Interoperate with All the Things

#117

Post by chromatic »

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…

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 didn't, and WASM won't.)

I endorse this point of view, from hard-won experience.

(Also: memory model. Always memory model.)

Re: WebAssembly Interface Types: Interoperate with All the Things

#118

Post by ori_b »

afiori wrote: post #95
ori_b wrote: post #36

Earlier quoted context omitted.

> 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 think Rust macros and C++ templates are not lazy wrt execution.

They are lazy wrt compilation. So, unless you use the specialization in C++ or Rust, there's no code to call.

    std::vector
Simply doesn't exist for interop code to call.

Re: WebAssembly Interface Types: Interoperate with All the Things

#119

Post by sideeffffect »

bcheung wrote: post #76
guhidalg wrote: post #70

Earlier quoted context omitted.

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

C# is the largest language for sure but it was designed for multiple languages from the start. There are things you can do in CIL and other languages that you can't do in C# even. Functional languages and pattern matching can be expressed quite well in .NET which aren't in C# (at least not yet fully). I think the statement that the CLR ties you to C# is not justified. Can you elaborate why you think this is the case?…

> statement that the CLR ties you to C# is not justified

it is. F# developers are stuck with the language progress and can't (or don't want to) add big and important features like Type Classes or Higher-kinded Types, until C# adds them first

https://github.com/fsharp/fslang-suggestions/issues/243

Post reply on HN