WebAssembly Interface Types: Interoperate with All the Things

Post by sroussey » Thu, Aug 22, 2019, 12:06 AM UTC

bcheung wrote: post #90

wahern wrote: post #84

Earlier quoted context omitted.

WASM is tied to existing JavaScript engines and their constraints. For example, WASM doesn't support more efficient control flow because of the design of V8 (and possibly SpiderMonkey): http://troubles.md/posts/why-do-we-need-the-relooper-algorit... https://news.ycombinator.com/item?id=19997091

Tied to the engine is orthogonal to tied to the language. You can compile C, C++, and Rust to WebAssembly. But you still can't compile JS to WebAssembly. Given the large amount of code in JS and the number of JS developers, not being able to support a major general purpose language rules out WASM as a cross platform target in my book.

Post by pjmlp » Thu, Aug 22, 2019, 5:07 AM UTC

yellowapple wrote: post #87

pjmlp wrote: post #52

Earlier quoted context omitted.

Please, what wonderful feature does WASM have that neither JVM nor CLR are capable of? Or for that matter, the myriad of bytecode formats devised since UNCOL, like the IBM and UNISYS's language environments on their mainframes.

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…

Post by afiori » Thu, Aug 22, 2019, 6:19 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…

Post by pjmlp » Thu, Aug 22, 2019, 6:39 AM UTC

flohofwoe wrote: post #74

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.

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.

Post by jcelerier » Thu, Aug 22, 2019, 6:46 AM UTC

adev_ wrote: post #59

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.

> 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. Not Really. They worked With a plugin side to the browser and not really IN the browser. And that makes a big difference. Nor Java Applet, nor Sliverlight not even Flash were offering a smooth, integrated experience with in web page or application. I have…