Show HN: A tiny WASM compiler and runtime for demonstration purposes (luna-demo.vercel.app)

This is awesome! I too have wanted to conquer the WASM dungeon but haven't dedicated the time myself to approach the project. I'm eager to look through this repo and learn a thing or two from it.

Thanks for showing this! Today I learned that wasm has a text format thanks to you :)

I'm curious how small a conforming WASM implementation can be (Luna looks extremely small, but not conforming).

In particular I'm curious how feasible it is to create WASM polyfills for various languages. Imagine you have a nice C kernel that you want to wrap in various languages. In many cases you can use native extensions to wrap your C kernel through an FFI, and on the web you can use WASM in supported browsers. But what about cases where people can't use your native extension? Suppose they are using a browser that doesn't support WASM. It's nice to be able to offer a polyfill that at least works, even if it is slower.

The feasibility of this idea hinges on how easily you can write a conforming implementation of WASM in a bunch of different languages. But I don't know the WASM spec well enough to know how big of an undertaking this is.

I'm upset WASM doesn't have any types other than numbers, so you can't export any real-world functions without relying on glue code, which converts strings and objects to numbers and the other way around

this is also the reason why the "hello world" of WASM is a function adding two numbers - because there are no strings in WASM

https://webassembly.github.io/spec/core/syntax/types.html

You only just posted this (12 days ago, 75 points, 2 comments[0]), the vercel app seems to look the same, and still references the repo for instructions. This seems way to soon to be making a duplicate post.

[0]: https://news.ycombinator.com/item?id=33424354

I think it's interesting the amount of justification given for why this is being built. Twice in the same paragraph. And no doubt there will be hundreds more wondering why do create something that already exists. Software developers are too fixated on pragmatism. If you're writing code, the resulting code better be something useful OR ELSE.

Do you ever ask someone why they're doing a crossword puzzle? Playing a video game? Trying to get of an Escape Room?

No. But if someone say writes their own Lisp as an exercise, oh the vitriol from the pragmatists.

I've personally stopped answering that question.

Please take these as suggestions and not criticism :)

https://github.com/thomscoder/luna/blob/009b20c9afd88d0a6572...

The list splitting here is currently un-necessary. Your example for users is

   const result = startAeonRuntime(wasmBinary, "addNumbers", n1, n2, n3);

So you can just do something like

   const startAeonRuntime(wasm, funcName, ...params) => {
       const ast = createAST(wasm);
       return invokeFunction(ast, funcName, ...params);
   }

However, this leaves me with questions. Why should we need to create/parse the AST each time we want to invoke a function? A wasmBinary can provide multiple functions. Creating the AST each time seems extremely wasteful, but also a bit confusing since I don't think it's necessary. My personal opinion is the function "startAeonRuntime" should be more something like "createAeonRuntime" that returns a partially parameterized version of invokeFunction that I can re-use over and over without it needing to create an AST each time. So something like

In user code I have

    const runtime = createAeonRuntime(wasmBinary);
    const additionResult = runtime("addNumbers", 1, 2, 3);
    const multiplicationResult = runtime("multiplyNumbers, 2, 4, 6);

Then in the library for the runtime the implementation looks like.

    const createAeonRuntime = (wasmBinary) => {
        const ast = createAST(wasmBinary);
        return (funcName, params) => invokeFunction(ast, funcName, params);
    }