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.
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.
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:
- https://christine.website/blog/olin-1-why-09-1-2018
- https://christine.website/blog/olin-2-the-future-09-5-2018
These will explain a lot that hasn't been fit into here yet.
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.
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.goproduces 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.