Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly from Scratch: From FizzBuzz to DooM

github.com

Post reply on HN
Print view View original

91–95 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#91

Post by afiori »

pjmlp wrote: post #54
flohofwoe wrote: post #47

Earlier quoted context omitted.

I think if you're afraid of memory corruption inside the WASM heap, it's better to use Rust instead of C or C++. WASM's job is to prevent code inside the sandbox from escaping the sandbox, not to prevent memory corruption inside the sandbox.

> I think if you're afraid of memory corruption inside the WASM heap, it's better to use Rust instead of C or C++. Agreed, but as consumer from WASM modules that isn't your option to make. > WASM's job is to prevent code inside the sandbox from escaping the sandbox, not to prevent memory corruption inside the sandbox. That is not better than a typical OS process, just it happens to be randomly downloaded into my comp…

It is a lot better: there is a sandbox with minimal surface area compared to no sandbox at all (except for memory isolation)

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#92

Post by pjmlp »

afiori wrote: post #91
pjmlp wrote: post #54

Earlier quoted context omitted.

> I think if you're afraid of memory corruption inside the WASM heap, it's better to use Rust instead of C or C++. Agreed, but as consumer from WASM modules that isn't your option to make. > WASM's job is to prevent code inside the sandbox from escaping the sandbox, not to prevent memory corruption inside the sandbox. That is not better than a typical OS process, just it happens to be randomly downloaded into my comp…

It is a lot better: there is a sandbox with minimal surface area compared to no sandbox at all (except for memory isolation)

When they are finished with the WebAssembly roadmap there will be the same sandbox as a typical OS process, no different of running a ART executable on Android, bitcode on watchOS, MSIL on Windows, or TIMI on IBM i.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#93

Post by afiori »

pjmlp wrote: post #92
afiori wrote: post #91

Earlier quoted context omitted.

It is a lot better: there is a sandbox with minimal surface area compared to no sandbox at all (except for memory isolation)

When they are finished with the WebAssembly roadmap there will be the same sandbox as a typical OS process, no different of running a ART executable on Android, bitcode on watchOS, MSIL on Windows, or TIMI on IBM i.

Of course, that is the plan, but even then it will still be possible to run WebAssebly modules with no permissions or limited permissions, as the sandbox was always there.

On the other hand I need to admit that I would have not forseen some of the more recent use cases for WebAssembly

https://bytecodealliance.org/articles/making-javascript-run-...

which can be reminescent of the "docker daemon running as root" issue.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#94

Post by djhworld »

sitkack wrote: post #67
djhworld wrote: post #31

Earlier quoted context omitted.

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have b…

Why this arch over having the UI run in the main thread and sending events into the wasm worker?

I'd ported the emulator to WASM from one I'd half written a few years previously, and engineered myself into a corner (+ like I said, not a web programmer)

The emulator ran in the worker, and the inputs were handled on the main thread.

The output (i.e. display) was pushed from the worker -> main thread

I think if I was to do it from scratch I'd do something similar to the DooM approach here and use renderAnimationFrame etc

If you're interested I wrote about it a few years ago but haven't touch it since https://djharper.dev/post/2018/09/21/i-ported-my-gameboy-col...

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#95

Post by masklinn »

mamcx wrote: post #32
flohofwoe wrote: post #10

Earlier quoted context omitted.

What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Ja…

>What type of strings though? The good one! UTf-8, NOT null terminated, pascal like. ie: what rust have: https://doc.rust-lang.org/std/string/struct.String.html REPEAT the mistakes of C (and considering the security angle! in a browser!) must be a big no.

> UTf-8, NOT null terminated, pascal like. > > ie: what rust have: > > https://doc.rust-lang.org/std/string/struct.String.html

Rust (or C++) strings are not pascal strings. In pascal strings, the "string buffer" also contains the length information, and historically it was all bytes with a length byte at the start, which was why your strings started at index 1 and limited to 254 bytes.

It's possible to modernise this style of strings to be less crummy (that is essentially what sds does), but C++/Rust string are a third take where the length (and capacity) are stored separately from the string buffer, and that buffer is always on the other side of a pointer (ignoring SSO, which Rust sadly doesn't have due to the original interface definition).

Post reply on HN