olin
Olin is like the JVM for WebAssembly. It wraps WebAssembly with a set of
functions to access the outside world and keeps track of things like how
many instructions were used, how many syscalls were made and how much memory
was used. This helps with profiling code.
To view Olin in action, click here.
Background
Very frequently, I end up needing to write applications that basically end up
waiting forever to make sure things get put in the right place and then the
right code runs as a response. I then have to make sure these things get put
in the right places and then that the right versions of things are running for
each of the relevant services. This doesn't scale very well, not to mention is
hard to secure. This leads to a lot of duplicate infrastructure over time and
as things grow. Not to mention adding in tracing, metrics and log aggreation.
I would like to change this.
I would like to make a prescriptive environment kinda like Google Cloud Functions
or AWS Lambda backed by a durable message queue and with handlers
compiled to webassembly to ensure forward compatibility. As such, the ABI
involved will be versioned, documented and tested. Multiple ABI's will eventually
need to be maintained in parallel, so it might be good to get used to that early
on.
I expect this project to last decades. I want the binary modules I upload today
to be still working in 5 years, assuming its dependencies outside of the module
still work.
Blogposts
Before asking questions or using Olin in this early state, I ask you please read
these blogposts outlining the point of this project and some other bikeshedding
I have put out on the topic:
These will explain a lot that hasn't been fit into here yet.
ABI's Supported
Common WebAssembly
Olin includes support for binaries linked against the Common WebAssembly
specification. Please see the tests in cmd/cwa
for more information. Currently
the Common WebAssembly is fairly basic, but at the same time there are currently
the most tests targeting Common Webassembly.
The tests for the Common WebAssembly spec can be found here.
Go
Olin also includes support for running webassembly modules created by Go 1.12's webassembly support.
It uses the wasmgo
ABI package in order to do things. Right now
this is incredibly basic, but should be extendable to more things in the future.
As an example:
// +build js,wasm ignore
// hello_world.go
package main
func main() {
println("Hello, world!")
}
when compiled like this:
$ GOARCH=wasm GOOS=js go1.12.1 build -o hello_world.wasm hello_world.go
produces the following output when run with the testing shim:
=== RUN TestWasmGo/github.com/Xe/olin/internal/abi/wasmgo.testHelloWorld
Hello, world!
--- PASS: TestWasmGo (1.66s)
--- PASS: TestWasmGo/github.com/Xe/olin/internal/abi/wasmgo.testHelloWorld (1.66s)
Currently Go binaries cannot interface with the Dagger ABI. There is an issue
open to track the solution to this.
Future posts will include more detail about using Go on top of Olin.
Under the hood, the Olin implementation of the Go ABI currently uses Dagger.
To follow the project, check it on GitHub here. To talk about it on Slack,
join the Go community Slack and join #olin
.