It's September 1, let's try something different. Problem - I'm usually wiped out at the end of the day to be articulate (or at least, articulate as I'd like to be). Solution - write notes throughout the day on what I plan to write about.
As an aside, my blog posts are paying off already - I referred to a previous post on the simplest way to compile Rust to WebAssembly, instead of my notes.
I know. I've been going on about WebAssembly for a while now. Part of it is accountability. It's an incentive for me to learn something I keep going on about to avoid embarrassment. I do believe the responsiveness that WebAssembly provides would accelerate the shift of native apps to be run in the browser. Yesterday I realized it could be even more groundbreaking.
Sara shared what's she's reading on her blog, it's a fantastic list. The post by Andreas Rossberg on Motoko had a link to a comprehensive discussion of WebAssembly in the Communications to the ACM (direct link here), as well as the following quote.
Wasm’s main difference compared to other virtual machines is that it is not optimized for any specific programming language but merely abstracts the underlying hardware, with a byte code directly corresponding to the instructions and memory model of modern CPUs. On top of that, Wasm supports sandboxing through strong modularity and a rigid mathematical specification that ensures that execution is safe, free of undefined behaviour, and (almost) entirely deterministic. Moreover, these properties actually have a machine-verified mathematical proof!
I've decided I'm going to come up with my own resources. Watch this space.
The advantage of going through a book is comprehensiveness. In the book I found the answer to a previous question posed - why do you need a web server to run WebAssembly? It turns out cross-scripting rules in the browser blocks reads to the file system.
Re: portability, when I compile Rust on my laptop, the base target is stable-x86_64-apple-darwin, i.e. version-processor-OS. For WebAssembly, it's wasm32-unknown-unknown, i.e. it's designed to be compile once, run everywhere!
Last week I briefly mentioned portability of C, let's complete that thread. C binaries would only work for a specific OS, so C when compiled for Linux would not work on Windows. Java, however, is compiled to Java bytecode that would run on any Java VM by design. Thus Java achieves portability across operating systems, which extends to all JVM-based languages - Clojure, Groovy, Kotlin, Scala. It's the original compile once, run everywhere.
Content: Python interpreters
Coming across RustPython made me look up Allison Kaptur's post on 500 lines or less: A Python interpreter written in Python.
I then discovered this is something she worked on while at RC!