Despite the title, this blog post goes very deep into how a compiler generates WASM and what that looks like.
Lots of hacks as WASM is pretty unfinished as it is, specially regarding linking different modules and the calling convention. The author used the Zig compiler to figure out how to do those things (Zig just does what C does, it seems).
I've tried doing something similar, but gave up because of that.
Yeah I guess the problem is that WASM has only i32 i64 f32 f64, so there's no consensus on what a char* argument or return value looks like?
I'm a little surprised that hasn't been worked out by now
Most C structs seem to have obvious encodings in WASM ? Or is that not the right way to think about it?
There are all sorts of problems with linking with C++ exceptions and so forth, and probably varargs, but I would have thought basic C / Zig stuff would be worked out
Nonsense, if you're going to invest time in, say, writing a transpiler from C to some 4D stack language, then you'd at least give a reason why. Same with this, why not stick with zig, even just a cursory exposition of context is entirely absent from this article.
The number of votes this post has would perhaps imply that a non-zero number of people saw the point in this. Sorry if you didn’t. It’s someone’s blog post. Not everyone is vying for your attention and needs to tailor their writing to justify you looking at it.
When I don't know about the subject matter in a post, my first instinct is to research it myself for a bit to see if I can figure it out. I would recommend you to do the same.
I gave a talk at OSS Summit and I explicitly addressed this in my talk with the slide that says "I cannot sell you Wasm"
Nobody asked this question after. I assumed that everyone who came to my talk had already been convinced, and the members of the audience all agreed or at least didn't complain.
The problem with explaining "why Wasm" is that you're looking (*I'm assuming a lot here) for direct effects, but I'm seeing most of the benefit coming from second-or-third-order effects.
I did focus on "what exactly is Wasm" and with a specific bent, from a Rubyist's perspective, how will and won't I be able to use Wasm today. It might not be the talk you're looking for if you don't care about a Rubyist's perspective.
From my perspective, Wasm helped me like this: I knew that I wasn't going to be able to rewrite my whole system and pack it into a Wasm, because reasons (Ruby...) so I decided, we'll have to find another way to make use of Wasm. Let's use it for the most important thing that isn't very important first (some core logic that is tightly scoped and exceedingly easy to verify.) It will help if we can show with a benchmark or something later that the whole process runs faster because this one part that runs 10,000 times is using Wasm now, hypothesis.
Accepting up front that this may not pan out immediately, because reasons (again) we tried to see what it will look like if the HTML parsing is done by Wasm. Well we figured out pretty quick that if we had to load and unload the Wasm every time it's used, that's not going to be an improvement unless it happens fast. And as long as we had to bundle the entire Ruby interpreter in with the Wasm, it probably wasn't going to load very fast. Experimentally verified with several runtimes.
So Wasm turned from "use any language!" to "any language, but not only that one..." real quick. And I was prepared to accept that I might need to use a different language, because I had seen the numbers this time, and I had been well coached and was prepared to blame it on Ruby. Wasm incentivized me to pick up a bit of Rust. Not because Rust is especially well-suited to solving my problem, but because any language could do it, and the performance-critical part probably shouldn't be in Ruby (and Rust in Wasm has the home-field advantage, I think.)
But, for me, the event-management code can all remain Ruby because it is in no way performance critical.
I mean, you could have just told me that Ruby is going to be a bottleneck when I get to performance-critical sections and we might have started with a different language, but "I'm a Rubyist" and I don't think that way. There's only one performance-critical part, so there isn't really a great argument to rewrite the whole thing in some other language (maybe Go instead of Rust...) but now that I have solved the core problem in Rust, I can just take that with me and use it with Go instead of a Ruby scaffold, if that was a thing of value to me. (It's not a difficult argument to make that you should just go ahead and build Kubernetes operators in Go rather than building them in Ruby.)
More important than the portability though, this exercise encouraged me to draw a box around the core bits of my program and think really hard about them until they were really solved. Separating those "business logic" bits from the rest of your program and making them pluggable is a really valuable thing to have, architecturally, even if you never swap the bits or the scaffold. Sure, you can write properly unit-ized code without Wasm to help you figure out this border-crossing situation,
...but can you coach a intern or junior engineer to do it with a soft touch and minimal instruction?
That was the a-ha moment for me. Wasm as a set of constraints naturally promotes and encourages the emergent solutions to look like this one, drawing a (sand)box around each important component. You won't build a monolith if it cannot do dynamic loading.
(So this next stage of Wasm ecosystem development, with the new component loaders capability, is set to make things quite interesting again... buckle up!)
Lots of hacks as WASM is pretty unfinished as it is, specially regarding linking different modules and the calling convention. The author used the Zig compiler to figure out how to do those things (Zig just does what C does, it seems).
I've tried doing something similar, but gave up because of that.