Hacker News Reader

Comment by firtoz | Hacker News Reader

> For instance, modern operating systems can handle 64-bit numbers. WebAssembly, however, is limited to 32 bits, and can access only 232 bytes (4 gigabytes) of memory. Furthermore, it cannot directly access a computer’s file system or its open network connections. And it’s not multithreaded; many algorithms depend on this form of parallelization, which allows different parts of a computation to be performed simultaneously. “A lot of older code won’t compile into WebAssembly, because it assumes that it can do things that can’t be done,” Stagg says.

I am surprised by the memory and 32 bit limitations... Are there plans to overcome them?

Edit: found it, https://github.com/WebAssembly/memory64

View on HN

>Furthermore, it cannot directly access a computer’s file system or its open network connections.

Those are its two strongest features, not bugs. If you're not going to respect those, just use native code, and the broken ambient authority model of computing, which never works out in the long run.

Edit: The article doesn't focus much on these limitations, but I think that putting up with the current limitations of WASM in terms of memory size or lack of threading might suck, but it's worth the ability to just try things out and run them without risking your whole computer.

Younger folks who never had a PC with only write protectable floppy drives missed out on a wonderful care-free period when you could just TRY OUT any new software, and your other data was safe, no matter what.

> Younger folks who never had a PC with only write protectable floppy drives missed out on a wonderful care-free period when you could just TRY OUT any new software, and your other data was safe, no matter what.

This goes so far now with sandboxing and virtual machines. I think the experience spawning VM to run and test new software is annoying but I guess it is still better than the annoying stuff from that era.

Disclaimer: I am one of those younger folks and probably naive in terms of that era.

We didn't have magical slabs of glass that could emulate a whole VAX VMS 11/780 system as a fun exercise in nostalgia, like my cheap ass Motorola phone can ;-)

We were living in an era where floppy disks were so much faster than punch cards, paper tape, cassettes, or just typing in programs after boot.

VMs and Sandboxes get close, but there's always the danger of virtual machine escape. WASM should be able to get us there, if we can keep people from wanting to make it Posix compatible and giving it file/network access.

It's so appalling to me to see such brazen advocacy for read only computing. This is such a teenie tny narrow little window of computing. Nothing should be consigned to sch irrelevances.

Back in the read-only OS days, we had a crude, but extremely effective capability system. I'm not asking for a return to 1985, but I do want things to be as safe now as they were back then. While there are places for things to hide in hardware now that didn't exist back then, the operating system models haven't been updated in 40 years, in terms of the use of the users authority.

It's equivalent to handing your wallet to the cashier any time you make a cash transaction... which nobody does except as a last resort in extenuating circumstances.

I agree about the disk and networking access limitations, was mainly concerned about the 32/64 bit limitations and the memory

The quote is a bit misleading. Traditional WASM (wasm32) does have 64-bit numbers (both a 64-bit integer type, and 64-bit floats), but the address space is limited to 32-bits (and thus pointers are 32-bits too).

AFAIK the downside of wasm64 is that it cannot use some virtual memory tricks to get rid of software range checks, so if memory access performance matters and a large address space isn't needed it probably still makes sense to stick with wasm32 even when wasm64 is available.

PS: see discussion here: https://github.com/WebAssembly/memory64/issues/3

Similarly for threads: https://github.com/webassembly/threads

Wait, can't web assembly use workers? It would be the same kind of architecture like with workload shared over a range of devices and receiving responses in random order, but in this case from worker threads

Strangely enough wasm might get support for 64 bit ints, but their native R code won't.

Reply on news.ycombinator.com