WebAssembly is more than the web • Hacker News Board

Re: WebAssembly is more than the web

#61

Post by gioele » Sat, Jul 14, 2018, 10:27 AM UTC

oaiey wrote: post #42

panic wrote: post #15

I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…

I share that view. Currently each high level language compiles to its own thing creating huge islands of code. C#, Java, Go, Rust, C etc will all compile their frameworks into the wasm files with very simple facade interfaces. The overhead will be enormous. Also the core is abstraction like memory and thread management is far from here. It will take a decade to figure that out. Till then, wasm is good for single apps…

> Currently each high level language compiles to its own thing creating huge islands of code. C#, Java, Go, Rust, C etc will all compile their frameworks into the wasm files with very simple facade interfaces.

This is more or less what SmallTalk has been doing for ages. The keyword for that is "image", in particular "single image".

And yes, it poses interoperability problems: http://www.ianbicking.org/where-smalltalk-went-wrong.html

Re: WebAssembly is more than the web

#62

Post by gioele » Sat, Jul 14, 2018, 10:32 AM UTC

white-flame wrote: post #9

krylon wrote: post #2

At the risk of sounding like an old grumpy guy[0], isn't this kind of what Java[0] set out to achieve some 20 years ago? I am in no position to compare the two by any metric other than age. But I am old enough to appreciate how such ideas tend return every couple of decades. Is this an IT thing, or is this phenomenon known in other areas, too? [0] I am not even that old, and I do my best to not be grumpy. [1] Yes, ye…

Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably. Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level, so even runtime language VMs can run in such a model withou…

> Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably.

> Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level [...]

The only real difference between the JVM and WASM is that the JVM came from the academic world of "stack-based VMs are better" while WASM comes from the world of "register-based VMs are better".

Both have the same limitations that all the other VMs have. And languages are equally difficult to port to either of them.

What WASM has (and the JVM always lacked) is a compatible zero-friction VM installed on more or less every computer of this planet.

This is the _"everywhere"_ that Java and the JVM wanted but never had.

Re: WebAssembly is more than the web

#63

Post by titzer » Sat, Jul 14, 2018, 10:37 AM UTC

As one of the co-founders of WASM, I can say, yes, the layering was a deliberate design decision for exactly the reasons laid out in the article.

Glad this is penetrating the wider consciousness.

Thanks for writing this, Steve!

Re: WebAssembly is more than the web

#64

Post by jules » Sat, Jul 14, 2018, 10:51 AM UTC

gioele wrote: post #62

white-flame wrote: post #9

Earlier quoted context omitted.

Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably. Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level, so even runtime language VMs can run in such a model withou…

> Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably. > Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level [...] The only real difference between the JVM and WASM…

Wasm is stack based too. The way data flow is encoded is not so important. A compiler can easily generate code for either a stack machine or a register machine. The VM will decode that into SSA again, so it only matters insofar as the representation has to be compact and fast to decode.

The main difference is that the JVM has a garbage collected heap and high level instructions for OOP, whereas wasm is lower level than C and only slightly higher level than assembly. Instead of an object model with GC you have raw pointers.

Re: WebAssembly is more than the web

#65

Post by jules » Sat, Jul 14, 2018, 11:05 AM UTC

Jasper_ wrote: post #20

white-flame wrote: post #9

Earlier quoted context omitted.

Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably. Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level, so even runtime language VMs can run in such a model withou…

Unfortunately, as a side effect of it supporting only one memory model, it means that the host code only has a giant memory bag to work with, meaning it needs to reconstruct objects from a giant heap. Currently, anything involving more complex host interaction (say, handles to kernel objects like files) is punted on to either the host-bindings proposal (which has a number of issues and basically was agreed was not a…

A generic object model will be a poor fit for many languages. I hope they keep it simple and low level and don't build in an object model. I'd rather have low level features that let you implement your own GC than a built-in object model. If you have zero cost exceptions and multiple function entry points you can implement your own GC, and coroutines and various other constructs without any more overhead than if you were compiling directly to machine code.

Basically, zero cost exceptions let you unwind and capture the stack while not slowing down the common case, and multiple entry points let you build the stack back up without compiling a large amount of duplicate code. This gives you arbitrary stack manipulation without explicit stack manipulation support in the VM. It enables features that usually require special VM features, such as GC, coroutines, lightweight threads, (delimited) continuations, effect handlers, C# style async.

Re: WebAssembly is more than the web

#66

Post by imtringued » Sat, Jul 14, 2018, 11:08 AM UTC

w1nt3rmu4e wrote: post #23

WebAssembly isn't just a cross platform technology, it's also a way to target platforms that are currently walled gardens. Being able to run software on e.g., the iPad without paying Apple's 30% fee and being able to ship features / bug fixes without added delays is a big deal. "Write-once, run everywhere without paying someone for the privilege" I think the term's overused, but this could actually be a "game changer…

If were to Apple or Google block wasm on iOS/Android then it's momentum would slow down significantly.

Re: WebAssembly is more than the web

#67

Post by jackpeterfletch » Sat, Jul 14, 2018, 11:11 AM UTC

TomMarius wrote: post #14

conradev wrote: post #12

Earlier quoted context omitted.

I would say that JVM bytecode is significantly higher level than WebAssembly, no?

Yes, and the whole browser plugin and plugin applet communication layers are missing, WASM runtime is embedded directly in V8 so the WASM code literally is ran closer to the metal.

WASM runs directly on V8, which runs natively.

Bytecode runs directly on the JVM which runs natively.

I'm not seeing how eithers closer to the metal.

Re: WebAssembly is more than the web

#68

Post by imtringued » Sat, Jul 14, 2018, 11:11 AM UTC

bluetech wrote: post #13

I think it would be neat if WebAssembly were embedded in other languages, like it is in JavaScript now. For example, suppose Python had a WebAssembly engine. I bet that could replace a lot of C extensions, and it would be as portable/universal as pure Python code, so no need for C compilers, OS-specific binary packages, etc.

It would certainly make "application level code" more portable (which is still a big win) but some sort of OS specific library still needs to talk to the filesystem, network, etc.

Re: WebAssembly is more than the web

#69

Post by TomMarius » Sat, Jul 14, 2018, 11:24 AM UTC

jackpeterfletch wrote: post #67

TomMarius wrote: post #14

Earlier quoted context omitted.

Yes, and the whole browser plugin and plugin applet communication layers are missing, WASM runtime is embedded directly in V8 so the WASM code literally is ran closer to the metal.

WASM runs directly on V8, which runs natively. Bytecode runs directly on the JVM which runs natively. I'm not seeing how eithers closer to the metal.

JVM yes, but when Java web apps were popular, there was a communication layer between the JVM application and the JVM support plugin, and then between the plugin and the browser.

Re: WebAssembly is more than the web

#70

Post by steveklabnik » Sat, Jul 14, 2018, 11:56 AM UTC

panic wrote: post #15

I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…

Yup; each embedding environment will need to spec an ABI, just like any other platform that exists. This is a possible future, not one that is 100% for sure happening.

The blocking thing has some solutions in the browser, like web workers, but that'll be fixed in time too. Emscripten can already do the OpenGL -> WebGL thing, incidentally.