Tangential: I decided to write a Wasm parser (more precisely, a decoder the the Wasm binary format) from scratch, as a means to learn both Wasm and Rust[0].
It was the first time I was writing this sort of thing, but I found the spec very clear and well-written.
Fun fact: I was surprised when the test from a toy parser surfaced a real regression in version 3 of the spec[1], released roughly 4 months before.
Slowly but steadily implementing support for version 3 of the Wasm specification in my wasm parser (written from scratch): https://github.com/agis/wadec
I plan to continue building the hobby project I started (a Wasm module parser[1]) by implementing version 3 of the WebAssembly specification and eventually implementing the Validation phase.
As a means to learn about both WebAssembly and Rust, I started writing a WebAssembly binary decoder (i.e. a parser for `.wasm` files) from scratch.
Recently it hit v2.0 spec conformance. 3.0 is next on the roadmap. (I'm executing it against the upstream spec test suite.)
I don't plan to make it a highly-performant decoder for use in production environments, but rather one that can be used for educational purposes, easy to read and/or debugging issues with modules. That's why I decided not to offer a streaming API, and why I'll be focusing on things like good errors, good code docs etc.
I'd say jump straight to the specification (maybe v2, which is simpler).
But I occasionally saw one or two articles around where they explain how the binary format works, which could be a good introduction before jumping to the spec.
Really happy to see Pat keeping it up! His first Ruby under a Microscope book but also his blog posts are amazing and a major source of inspiration for me. I did meet him personally in a Euruko conference. Such a great person.
As a means to learn about both WebAssembly and Rust, I started writing a WebAssembly binary decoder (i.e. a parser for `.wasm` files) from scratch.
Recently it hit v2.0 spec conformance. 3.0 is next on the roadmap. (I'm executing it against the upstream spec test suite.)
My aim is probably not for it to become a highly-performant decoder for use in production environments, but rather one that can be used for educational purposes and/or debugging issues with existing modules. That's why I decided not to offer a streaming API, and why I'll be focusing on things like good errors, good code docs etc.
As a Rust newbie and seasoned Go dev, I'm pretty interested to knownwhere would people experienced in both OCaml and Haskell, would put it in the spectrum.
Languages have features/constructs. It's better to look at what those are. And far more importantly: how they interact.
Take something like subtyping for instance. What makes this hard to implement is that it interacts with everything else in your language: polymorphism, GADTs, ...
Or take something like Garbage Collection. It's presence/absence has a large say in everything done in said language. Rust is uniquely not GC'ed, but Go, OCaml and Haskell all are. That by itself creates some interesting behavior. If we hand something to a process and get something back, we don't care if the thing we handed got changed or not if we have a GC. But in Rust, we do. We can avoid allocations and keep references if the process didn't change the thing after all. This permeates all of the language.
My team still has 8 year old Haskell systems in production. We pivoted away from the language a few years ago, which I discuss here a bit: https://qht.co/item?id=37746386
I personally love ML languages and would be happy to keep developing in them, but the ecosystem support can be a bit of a hassle if you aren't willing to invest in writing and maintaining libraries yourself.
OCaml has some high profile use at Jane Street which is a major fintech firm. Haskell is more research oriented. Both are cool, but wouldn't be my choice for most uses.
It was the first time I was writing this sort of thing, but I found the spec very clear and well-written.
Fun fact: I was surprised when the test from a toy parser surfaced a real regression in version 3 of the spec[1], released roughly 4 months before.
[0] https://github.com/agis/wadec
[1] https://github.com/WebAssembly/spec/issues/2066