alt Hacker NewsWASM seems to be rather poorly documented in general. I used to think it is only badly documented in Ruby (which it is), but I have been slowly reading "WebAssembly The Definitive Guide" and when comparing this to information on the internet, it seems WebAssembly is years behind e. g. HTML, CSS, or JavaScript in regards to documentation. Granted, it is not the same user base (more people will be interested in HTML and CSS simply because there is a bigger pool of people interested in that, rather than in WebAssembly), but still - documentation appears to become really worse in general on the internet. Finding it too.
So in this regard, having more implementations may be useful (more opportunity to improve documentation) - thus while I am in general skeptical, this is good news here, even if I do not use Go myself.
Replies
Interesting; I've been using WebAssembly as a compilation target for various projects for the past four years, and have been fairly happy with the state of documentation. I've never heard of that book you mentioned (I should check it out!), and instead I just read the spec directly: https://webassembly.github.io/spec/core/
Or occasionally I Google specific Wasm instructions and find .wat examples for them on MDN.
I'm sure you're right that the documentation is years behind that of HTML and CSS, but is there some specific aspect of Wasm documentation that you find lacking that isn't covered by the spec?
WASM is also like two decades younger than HTML and CSS and generally useful to a small fraction of the audience.
I wonder if your question relates to WASM or things in the WASM-sphere like WASI et al?
I'm not sure if it's right but I think of WASM as just an ISA and I guess the documentation seems to cover instruction encodings and semantics.
WASM development is really for a "level lower" than HTML, CSS, and JavaScript development. I know this because, being curious about it myself, I tried a year ago to make use of a WASM runtime in Go to run a piece of WASM code (I think I wrote something in V and compiled it to WASM).
It becomes a huge pain in the bum as soon as you have to deal with moving anything more than trivial types around, because you have to manually allocate memory for the WASM runtime and move bytes around. The byte representation needs to be understandable by the source language for your WASM code (the v language in my case). This is why these WASM runtimes use ints in their README examples, it would look and be horrendously complex otherwise.
If one is looking to use WASM for something for plugin development in the backend, I would try and look for something that is not WASM generic, but works with the source language, and where the WASM aspect is an under-the-hood detail.