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

71–80 of 119 posts

Re: WebAssembly Interface Types: Interoperate with All the Things

#71

Post by pjmlp »

k__ wrote: post #69
thesuperbigfrog wrote: post #50

Earlier quoted context omitted.

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?

https://github.com/oracle/graal

The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis.

As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System.

Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,....

IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability.

While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.

Re: WebAssembly Interface Types: Interoperate with All the Things

#73

Post by TeMPOraL »

pjmlp wrote: post #55
mrec wrote: post #38

Earlier quoted context omitted.

For a smallish subset of use cases, maybe. But replacing the DOM with a canvas-based UI for general use would be reinventing many of the problems of Flash.

Many designers and game devs see it otherwise.

Gamedev is a separate topic. As for designers, they are on the opposite side from users in the tug-of-war of control over content rendering. I don't believe they should get 100% of their way.

Re: WebAssembly Interface Types: Interoperate with All the Things

#74

Post by flohofwoe »

thesuperbigfrog wrote: post #50
Rusky wrote: 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.

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.

Re: WebAssembly Interface Types: Interoperate with All the Things

#75

Post by Rusky »

pjmlp wrote: post #71
k__ wrote: post #69

Earlier quoted context omitted.

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?

https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a…

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- and the latter doesn't support newer language standards and is being phased out.

WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.

Re: WebAssembly Interface Types: Interoperate with All the Things

#76

Post by bcheung »

guhidalg wrote: post #70
bcheung wrote: post #63

Earlier quoted context omitted.

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

Also, WASM is not tied to JavaScript. You can't even compile JavaScript to WASM because it doesn't support the necessary primitives. In fact other languages that are completely different than JavaScript compile to WASM much easier.

Re: WebAssembly Interface Types: Interoperate with All the Things

#77

Post by marcosdumay »

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

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.

Re: WebAssembly Interface Types: Interoperate with All the Things

#78

Post by Rusky »

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/

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.

Re: WebAssembly Interface Types: Interoperate with All the Things

#79

Post by chrisseaton »

Rusky wrote: post #75
pjmlp wrote: post #71

Earlier quoted context omitted.

https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a…

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

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

It does - LLVM bitcode.

Re: WebAssembly Interface Types: Interoperate with All the Things

#80

Post by Rusky »

chrisseaton wrote: post #79
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-…

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

Post reply on HN