WebAssembly: the importance of language(s)

This post originally appeared on Alice, Eve and Bob - a security blog.

Over at Enarx, we're preparing for another release. They're coming every four weeks now, and we're getting into a good rhythm. Thanks to all contributors, and also those working on streamlining the release process. It's a complex project with lots of dependencies - some internal, and some external - and we're still feeling our way about how best to manage it all. One thing that you will be starting to see in our documentation, and which we intend to formalise in coming releases, is support for particular languages. I don't mean human languages (though translations of Enarx documentation into different languages, to support as diverse a community as we can, is definitely of interest), but programming languages.

Enarx is, at its heart, a way to deploy applications into different environments: specifically, Trusted Execution Environments (though we do support testing in kvm). The important word here is "execution", because applications need a runtime in which to execute. Runtimes come in many different flavours: ELF ("Executable and Linking Format", the main standard for Linux systems), JVM ("Java Virtual Machine", for compiled Java classes) and PE ("Portable Executable", used by Windows), to give but a few examples. Enarx uses WebAssembly, or, to be more exact, WASI, which you can think of as a "headless" version of WebAssembly: whereas WebAssembly was originally designed to run within browsers, WASI-compliant runtimes support server-type applications. The runtime which Enarx supports is called wasmtime, which is a Bytecode Alliance project, and written in Rust (like Enarx itself).

This is great, but (almost) nobody writes native WebAssembly code (there is actually a "human-readable" format supported by the standard, but I personally wouldn't want to be writing in it directly!). One of the great things about WebAssembly is that it's largely language-neutral: you can write in your favourite language and then compile your application to a "wasm" binary to be executed by the runtime (wasmtime, in our case). WebAssembly is attracting lots of attention within the computing community at the moment, and so people have created lots of different mechanisms to allow their favourite languages to create wasm binaries. There's a curated list here, though it's not always updated very frequently, and given the amount of interest in the space, it may be a little out of date when you visit the page. In the list, you'll find common languages like C, C++, Rust, Golang, .Net, Python and Javascript, as well as less obvious ones like Haskell, COBOL and Scheme. Do have a look - you may be surprised to find support for your favourite "obscure" language is already started, or even quite mature.

This proliferation of languages with what we could call "compile target support" for WebAssembly is excellent news for Enarx, because it means that people writing in these languages may be able to write applications that we can run. I say may, because there's a slight complication, which is that not all of these compile targets support WASI, which is the specific interface supported by wasmtime, and therefore by Enarx.

This is where the Enarx community has started to step in. They - we - have been creating a list of languages which do allow you to compile wasm binaries that execute under wasmtime, and therefore in Enarx. You'll find a list over at our WebAssembly Guide and, at time of writing, it includes Rust, C++, C, Golang, Ruby, .NET, TypeScript, AssemblyScript, Grain, Zig and JavaScript[1]. You can definitely expect to see more coming in the near future. With this list, we don't just say "you can run applications compiled from this language", but provide a guide so that you can try each language for yourself! Currently the structure of how the information is presented varies from language to language - we should probably try to regularise this - but in each case, there should be sufficient information for someone fairly familiar with the language to write a simple program and run it in Enarx.

As I noted above, not all languages with compile target support for WebAssembly will work yet, but we're also doing "upstream" work in some cases to help particular languages get to a position where they will work by submitting patches to fix specific issues. This is an area where more involvement from the community (that means you!) can help: the more people contributing to this work, or noting how important it is to them, the quicker we'll gain support for more languages.

And here's where we hope to be: in upcoming releases, we want to be in a position where Enarx officially supports particular languages. What exactly that "support" entails is something we haven't yet fully defined, but, at minimum, we hope to be able to say something like "applications written in this language using this set of capabilities/features are expected to work", based on automated testing of "known good" code on a per-release basis. This will mean that users of Enarx will be able to have high confidence that an application working on one release will behave exactly the same on the next: a really important property for a project intended for commercial deployments.

How can you get involved? Well, the most obvious is to visit the page in our docs relating to your favourite language. Try it out, give us feedback or offer to improve the documentation if you think it needs it, or even go upstream and offer patches. If no such page exists, you could visit our chat channels and ask to see if anyone is working on support and/or create an issue requesting support, explaining why you think it's important.

Finally, to encourage upstream developers to realise how important supporting "their" language is, you can provide a GitHub star by visiting https://enarx.dev or https://github.com/enarx/enarx. "Starring" the project is a way to register your interest, and to show the community that Enarx is something you're interested in.

1 - Huge thanks to everyone involved in these efforts, with a special shout-out to Deepanshu Arora, who's done lots of work in this area.