Live data from Hacker News

WebAssembly is more than the web

words.steveklabnik.com

31–40 of 83 posts

Re: WebAssembly is more than the web

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

GC with structs and fields, host types, threads, etc are in the pipeline to address your concerns. While their implementation is coming along really slowly, I suppose that's better than hasty.

Re: WebAssembly is more than the web

#32
post #5

Earlier quoted context omitted.

>(more "close to the metal" let's say) I don't think that's really fair to say at all.

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

Not really, lot of parallels actually. But it does have higher level constructs than WASM currently has, but they are quite specific to Java the language. So I wouldn't say higher level, just more and larger scope currently.

Re: WebAssembly is more than the web

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

Another major difference to Java is that WASM doesn't come with any library whatsoever (as already implied by some sibling comments). The only interfaces to the outside world are function callbacks and shared memory. Callbacks have to be set up manually when loading the code into the VM.

While this makes integrating WASM code into applications a little awkward—you're basically down to peeking and poking addresses in memory, see [1] for some code I wrote that does exactly that—this has some key advantages.

First, the WASM designers cannot make any opinionated decisions regarding what a library should look like. Providing a library is entirely up to the particular toolchain you're using (e.g., Emscripten, which provides a partial libc). And it's up to you what toolchain you use (if any). Second, this facilitates perfect sandboxing. All you're doing is placing your input on a sliver of memory, running your program on the virtual WASM CPU, and reading back the result from memory (and/or responding to callbacks).

[1] https://github.com/astoeckel/linprog2d/blob/b557f69d00dcadfe...

Re: WebAssembly is more than the web

#34

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.

The Wasm tool chain is built around llvm. So, you can take some complex C code and target wasm instead of X86, ARM, or whatever. That works right now and you can already do things silly like compile emulators and vms to run in a web browser and get them to boot e.g. windows 95 or linux.

So, you could try to recompile the entire python ecosystem (interpreter, libraries, extensions, etc.) to wasm. This might be tricky right now because not all stuff readily compiles to wasm yet probably or uses gcc instead of llvm. Als, python has its own vm and compiler that would need to be reengineered on top of wasm.

Of course people have been working on moving python to llvm for some time so this might actually become feasible.

Re: WebAssembly is more than the web

#35
One thing I am concerned about is startup performance. On my (slow) Chromebook, some of my multi-megabyte WASM files take 10 seconds to compile. Seems we need either faster CPU cores, faster code generation, or some kind of staged JIT compile -- though I guess the latter could be accomplished today with sufficiently clever tooling.

Re: WebAssembly is more than the web

#36

This is technically web, but not in the way you might think. We (Cloudflare) are working on providing WASM support in our Workers [1] product that lets you run code in our 155 data centers around the world. WASM is great because we can run it in V8 isolates which are much lighter weight than containers or full VMs. [1] https://cloudflareworkers.com

Thanks for sharing, this looks very exciting! Bring on more docs and examples!!

Re: WebAssembly is more than the web

#37

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.

I totally agree with what you said. Currently I'm loading compiled C code with the Python foreign function interface (often not (solely) for performance reasons, but because it just so happens that I already have a C library that solves a particular problem). It would be great if I wouldn't have to worry about providing a shared library for all possible target platforms.

In fact, when I searched for a Python WebAssembly interpreter a few weeks ago I stumbled across this project [1]. So rest assured, people are working on this already.

[1] https://github.com/kanaka/warpy

Re: WebAssembly is more than the web

#38
Obligatory mention of this tongue in the cheek and visionary look presentation "The Birth & Death of JavaScript": https://www.destroyallsoftware.com/talks/the-birth-and-death...

This is basically what is happening with wasm and it's happening much faster Gary Bernhardt was anticipating in that presentation.

IMHO wasm finally displaces javascript as the only practical language to run stuff in a browser. Frontend stuff happens in javascript primarily because browsers cannot run anything else now that plugins have been killed off. Wasm changes that.

At the same time a lot of desktop apps are in fact javascript apps running on top of electron/chrome. Anything like that can also run wasm.

Finally people have been porting vms to javascript for pretty much as long as wasm and its predecessors have been around. So booting a vm that runs windows 95 or linux in a browser is not very practical but was shown to work years ago. This is what probably inspired the presentation above.

I've actually been pondering doing some frontend stuff in kotlin in or rust. I'm a backend guy and I just never had any patience for javascript. I find working in it to be an exercise in frustration. But I actually did some UI work in Java back in the day (swing and applets). Also there's a huge potential for stuff like webgl, webvr, etc. to be driven using languages more suitable to building performance critical software if they can target wasm. I think wasm is going to be a key enabler for that.

Most of the stuff relevant for this has been rolling out in the last few years. E.g. webgl is now supported in most browsers. Webvr is getting there as well. Wasm support has been rolled out as well. Unity has been targeting html5 + wasm for a while now. And one of the first things that Mozilla demoed years ago with wasm was Unreal running in a browser.

I would not be surprised to see some of this stuff showing up in OSes like fuchsia (if and when that ships) or chrome os.

Re: WebAssembly is more than the web

#39
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 was a language. They created a platform-independent bytecode associated with that language, but it was closely associated with the language itself. Webassembly is much more of a portable version of ordinary binaries.

Re: WebAssembly is more than the web

#40
> Eventually I’ll write a post about the wrong, but for now, the right: in some sense, WebAssembly is a different way of accomplishing what the JVM set out to do

I agree, it's exciting, but this is half (or less than) an article. These hyped-up technologies make me grumpy neck beard.

Post reply on HN