I'm in a process where application-level programming isn't cutting it anymore (I still have a lot to learn, but it's in the diminishing returns).
I've been looking to understand the entire stack at a deeper level (from how requests are made to how they're parsed), and this seems like the next natural step!
Wasm is such a cool technology. The spec though for me leaves a lot to be desired. Oh, the first few chapters are fine, but when you get to the binary and text formats that's when it all breaks down for me.
For whatever reason, Wasm loves OCaml. This wouldn't really be a bad thing if they didn't come up with their own custom language to denote syntactic elements of both formats instead of using EBNF or similar. I discussed this with them (because before this change they were using raw MathML for all the productions, and screen readers and MathML are... Erm... Hit and miss) and they noted that they needed an attribute grammar instead of just either BNF or an extension of it. So what they have now (SpecTec) is better than what they did have, and I like that I can now just open the raw grammar files and dive in. The problem is the way they chose to express it. And it could just be me, because ML languages (and functional languages in general) don't really come all that easy to me. (they're just... Really difficult for me to mentally follow, which is odd since I can follow most others just fine.)
I'm not gonna lie, this Little course book thing is incredibly fantastic. Well written, well structured code. It really helped me to connect the spec to the binary format in my brain.
Also because it uses Ohm.js to write the Parser/Lexer from a BNF definition, almost 100% of the focus is on WebAssembly and how to compile it, instead of flexing and parsing.
WebAssembly seems like a big workaround for JavaScript only supporting doubles, strings, and objects/arrays. Its big features are to allow using a byte array as stack/heap storage memory, and having actual integer types, along with allowing C code to be compiled to WebAssembly.
Oddly enough, Zig is the nicest C to WebAssembly compiler I've used so far.
The "official" wasi-sdk is quite similar, a prepackageded clang toolchain to compile c/c++ code to wasi. What makes emscripten more complicated is the browser integration (eg compiling into a ready-to-run html/js/wasm bundle and providing C API wrappers for various web apis), and Zig also only manages the "compile to wasm" part but lacks Emscripten's JS interop features (that's why in my zig+wasm experiments I use the Emscripten SDK as sysroot and linker).
What the Zig toolchain provides that neither the wasi-sdk nor emsdk have is a package manager and build system which are both much nicer than what the c/c++ ecosystem offers.
20 comments
[ 2.2 ms ] story [ 35.5 ms ] threadI see runtime interpreters as constraining when a system call is needed, but proscribed.
Beyond the sample chapters which are linked from the landing page, we also have a couple blog posts which may be interesting:
- A WebAssembly Interpreter: https://wasmgroundup.com/blog/wasm-vm-part-1/
- An older blog post, "A WebAssembly compiler that fits in a tweet" (https://wasmgroundup.com/blog/wasm-compiler-in-a-tweet), was also on HN earlier this year: https://news.ycombinator.com/item?id=42814948
I can't help but notice that in the editor screenshots there's type information in *.js files.
I want to run something that execs a command line tool, both in the browser. Doable yet?
I'm in a process where application-level programming isn't cutting it anymore (I still have a lot to learn, but it's in the diminishing returns).
I've been looking to understand the entire stack at a deeper level (from how requests are made to how they're parsed), and this seems like the next natural step!
Thanks a bunch!
For whatever reason, Wasm loves OCaml. This wouldn't really be a bad thing if they didn't come up with their own custom language to denote syntactic elements of both formats instead of using EBNF or similar. I discussed this with them (because before this change they were using raw MathML for all the productions, and screen readers and MathML are... Erm... Hit and miss) and they noted that they needed an attribute grammar instead of just either BNF or an extension of it. So what they have now (SpecTec) is better than what they did have, and I like that I can now just open the raw grammar files and dive in. The problem is the way they chose to express it. And it could just be me, because ML languages (and functional languages in general) don't really come all that easy to me. (they're just... Really difficult for me to mentally follow, which is odd since I can follow most others just fine.)
Also because it uses Ohm.js to write the Parser/Lexer from a BNF definition, almost 100% of the focus is on WebAssembly and how to compile it, instead of flexing and parsing.
Go buy it.
Oddly enough, Zig is the nicest C to WebAssembly compiler I've used so far.
What the Zig toolchain provides that neither the wasi-sdk nor emsdk have is a package manager and build system which are both much nicer than what the c/c++ ecosystem offers.