Live data from Hacker News

WebAssembly from the Ground Up

wasmgroundup.com

31–40 of 61 posts

Re: WebAssembly from the Ground Up

#31
Just went and bought it!

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!

Re: WebAssembly from the Ground Up

#32

Just went and bought it! 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!

Awesome! You're exactly the kind of person we were thinking of when we wrote the book…experienced programmers who are interested in understanding things at a lower level.

Let us know how it goes! You can find us in the book Discord, or email us at hello@wasmgroundup.com.

Re: WebAssembly from the Ground Up

#33
post #22

What's the state of wasm for porting multi-process code? I want to run something that execs a command line tool, both in the browser. Doable yet?

> I want to run something that execs a command line tool, both in the browser. Doable yet?

If it's not possible from Javascript, it's also not possible from WASM, it's as easy as that.

If your command line tool can be compiled to WASM and works within the restrictions of the browser sandbox, it's trivial. But if you want to start a native command line tool from within the browser, it's pretty much impossible (and for good readons).

There's also a grey zone if you need it to work in a specific runtime environment. For instance VSCode extensions allow to run POSIX command line tools compiled to WASI, and those can safely access parts of the filesystem (like reading and writing files in the current project directory).

Re: WebAssembly from the Ground Up

#35
post #22

What's the state of wasm for porting multi-process code? I want to run something that execs a command line tool, both in the browser. Doable yet?

> I want to run something that execs a command line tool, both in the browser. Doable yet? If it's not possible from Javascript, it's also not possible from WASM, it's as easy as that. If your command line tool can be compiled to WASM and works within the restrictions of the browser sandbox, it's trivial. But if you want to start a native command line tool from within the browser, it's pretty much impossible (and for…

I meant: I want a program compiled to wasm capable of running in the sandbox calling another command line tool also compiled to wasm.

Right now the call is through an exec system call, but that can be changed.

Re: WebAssembly from the Ground Up

#37
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.)

Re: WebAssembly from the Ground Up

#38
post #5

Earlier quoted context omitted.

You don't want to use PHP (a server-sided language) to solve a client-side problem.

I know a person who wrote Linux X Desktop Environment using PHP. Worked for them. It is general purpose programming language.

> [PHP] is general purpose programming language.

To be charitable, yes — PHP has access to low-level system details like the file system, sockets, and processes.

> I know a person who wrote Linux X Desktop Environment using PHP. Worked for them.

However: (a) "Worked for them" is an anecdote, not evidence of comparative suitability; (b) Don't confuse possibility with empirical fitness for purpose. Virtually all decisions are relative to alternatives [1]; (c) Even PHP describes itself as only a "general purpose scripting programming language" [2].

Note that "scripting language" itself can hide important differences. PHP 8 introduced JIT compilation [3] which helps.

[1] In negotiation terms, your BATNA (Best Alternative to a Negotiated Agreement). When evaluating technologies, don't forget the human cost, so consider your BATSHIT: Best Alternative To Shackling Humans In Tedium (or whatever expansion you prefer).

[2] https://www.php.net/

[3] https://upsun.com/blog/php-just-in-time-compiler/

Re: WebAssembly from the Ground Up

#40
post #37

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 dis…

Despite not being an ML programmer, I found the spec pretty easy to read for the most part. One of the least intimidating specifications I have ever read, surprisingly.
Post reply on HN