In this article, we make the case for serverless functions in Rust and WebAssembly, and demonstrate their use in machine learning and visualization.

You will learn how to create a simple function for machine learning and deploy a serverless web site around it, for free (unless a million people use it!).

First, what is Tencent?

Tencent is the biggest Internet company outside of the USA with over a billion active daily users. Its cloud computing arm, Tencent Cloud, is ranked among the top 5 cloud providers in the world by market share.

If you want to reach the world-wide market with your cloud services, Tencent Cloud should be near the top of your list.

Tencent Cloud is also a leading innovator in serverless computing with strong offerings ranging from Function as a Service (FaaS) runtimes, triggers, connectors, and developer tools.

The Tencent Serverless Cloud Functions (SCF) already support 10+ programming languages and runtime frameworks. But the recently released SCF Custom Runtime took another step forward. The SCF can now support functions written in any programming language.

In this article, I will cover how to run WebAssembly functions, written in Rust, in the SCF.

What we'll cover in this article

We will first go over the basic concepts. Then, we will review a complete but simple hello world example to deploy your first WebAssembly serverless function.

Finally, we will do something useful with a machine earning as a service (MLaaS) example that takes data and returns the fitted model and visualization in the SVG format.

Here is the final application you will create by the end of this tutorial. It is completely “serverless” and incurs cost when people use it.

The HTML and JavaScript UI can be hosted on any computer including your laptop, and the backend function to perform machine learning and SVG drawing is on Tencent Cloud Serverless.

Why WebAssembly and Rust

Traditional serverless functions are based on heavy-weight frameworks. Developers must write functions in specific application frameworks, such as JavaScript in Node.js or Python Boto and so on.

The Tencent Cloud SCF Custom Runtime breaks this mold, and allows developers to write serverless functions in any language.

To demonstrate this point, it provides examples for a Bash script-based function, a Deno-based TypeScript function, and a Rust-based native binary function. That allows us to create and deploy WebAssembly-based serverless functions on Tencent Cloud.

Why do we want to do that? Here are some reasons.

• WebAssembly is designed for performance. WebAssembly functions could be 10x faster than comparable programs written in JavaScript or Python.

• WebAssembly functions are portable. While it is possible to run native binaries on SCF Custom Runtime, those binaries must be compiled to the exact operating system environment for Custom Runtime. It is currently CentOS 7.6 on X86 CPUs, and could change later. WebAssembly functions are portable and very easy to deploy and manage as we will see.

• WebAssembly functions are safe. It is known that even with Docker, native binary applications could breach the container. Since your application probably depends on many 3rd-party libraries, the risk for rogue code in your dependencies is real. WebAssembly, with its capability-based security model, provides better runtime protection for your code.

• While WebAssembly is agnostic to programming languages, Rust, AssemblyScript (a subset of TypeScript), C/C++, and Go are among the best languages to write WebAssembly functions. In particular, Rust is a popular and fast rising programming language with a passionate community. It allows us to write highly efficient, yet memory safe, functions.

Finally, programming and deploy WebAssembly functions on Tencent Cloud is actually quite easy. You can do in it an hour. Let’s get started.

Prerequisites

First, sign up for a Tencent Cloud account. For most development and personal projects, you can probably staying within its free tier of service.

Then, on your local development computer or Docker container, make sure that you have Rust and ssvmup toolchain installed. The ssvmup toolchain compiles and optimizes Rust programs into WebAssembly bytecode.

Just use the following simple commands to install both. Or you can refer to this guide.

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ source $HOME/.cargo/env
... ...
$ curl https://raw.githubusercontent.com/second-state/ssvmup/master/installer/init.sh -sSf | sh

The WebAssembly function is executed in the Second State VM — a high-performance WebAssembly VM optimized for server-side use cases and applications.

Hello, world

To get started with your first Rust and WebAssembly function on Tencent Cloud, we encourage your to clone or fork this template repository on Github and use it as the basis for your own application.

The Rust function in main.rs is the serverless function we will deploy to SCF. As you can see from its source code, it reads the function’s input from STDIN, and then use the println! macro to send results to the STDOUT.

use std::io::{self, Read};
use serde::Deserialize;

fn main() {    
    let mut buffer = String::new();    
    io::stdin().read_to_string(&mut buffer).expect("Error reading from STDIN");    
    let obj: FaasInput = serde_json::from_str(&buffer).unwrap();    
    let key1 = &(obj.key1);    
    let key2 = &(obj.key2);    
    println!("Hello! {}, {}", key1, key2);
}

#[derive(Deserialize, Debug)]
struct FaasInput {    
    key1: String,    
    key2: String
}

The Rust main() function uses the serde library to parse a JSON string from STDIN.

The JSON looks like the following. The reason we write the function this way is because this is the built-in hello world JSON template SCF uses to test deployed functions.

{  
    "key1": "test value 1",  
    "key2": "test value 2"
}

The function extracts the key1 and key2 values and outputs the following hello message to STDOUT.

Hello! test value 1, test value 2

But, how does a web request to this function get translated into STDIN? And how does the function response in STDOUT get translated into a the HTTP response?

That is done by the SCF Custom Runtime infrastructure and the bootstrap program in our template.

As you can see, the bootstrap program is simply a bash shell program that continuously polls the SCF for incoming requests. It translates the incoming request to STDIN and calls the WebAssembly function through the SSVM. It then takes the STDOUT output and sends it back into SCF as the function’s response.

You do not need to modify the bootstrap program if you use our template.

Now, you can build the Rust function into WebAssembly bytecode with ssvmup, and then package a zip file for deployment on the Tencent Cloud SCF Custom Runtime.

$ ssvmup build

Follow the instructions and screenshots to deploy and test the hello.zip file from above. Now you have successfully deployed a WebAssembly serverless function!

Next, let's create a useful web service from a Rust function.

Machine Learning as a Service

For this example, we chose a computationally intensive machine learning task to demonstrate the performance of a Rust WebAssembly function.

The serverless function takes an input string of comma delimited numbers that represent a set of points on a 2-D plane. The input data format is x1,y1,x2,y2,....

The function analyzes the data and computes two Eigenvectors that indicate the directions of the most variance in the data.

The Eigenvectors give data scientists hints on the underlying factors that drives the variance in the data. This is called Principal Component Analysis (PCA).

Our function creates a SVG graph with the input data points as well as the Eigenvectors plotted on it. It outputs the SVG graph in XML text.

To get started with this example, you should clone or fork this repository. The project is in the tencentcloud/ssvm/pca folder. You can also copy the content of the Cargo.toml and src/*to your hello world template.

If you do the latter, make sure that you modify the Cargo.toml to point to the correct source code folder for our Rust machine learning library.

I will not go into the details of the Rust source code for PCA or SVG generation in this tutorial as they involve a fair amount of computational code. If you are interested, you can check out more resources at the end of this article.

You can follow the same process as in the hello world example. Use the ssvmup to build a pca.zip package and deploy it on Tencent Cloud SCF Custom Runtime.

Next, we want to associate the deployed function with a web API Gateway so that it can be invoked from a web HTTP or HTTPS request. Do that from the Trigger Management tab in the web console for SCF. See the instructions and screenshots here.

The API console turns an HTTP request into a JSON input to the serverless function. For example, here is an HTTP POST request to the API gateway URL. We put the comma delimited data points from the iris.csv file in the POST body.

$ curl -d @iris.csv -X POST https://service-m9pxktbc-1302315972.hk.apigw.tencentcs.com/release/PCASVG

The API Gateway passes the following JSON to the Rust function’s STDIN. The POST body is now the body attribute in the JSON.

{
  "body": "3.5,0.2,3,0.2,...",
  "headerParameters": {},
  "headers": {
    "accept": "/",
    "content-length": "11",
    "content-type": "application/x-www-form-urlencoded",
    "host": "service-aj0plx8u-1302315972.hk.apigw.tencentcs.com",
    "user-agent": "curl/7.54.0",
    "x-anonymous-consumer": "true",
    "x-api-requestid": "e3123014742e7dd79f0652968bf1f62e",
    "x-b3-traceid": "e3123014742e7dd79f0652968bf1f62e",
    "x-qualifier": "$DEFAULT"
  },
  "httpMethod": "POST",
  "path": "/my_hk",
  "pathParameters": {},
  "queryString": {},
  "queryStringParameters": {},
  "requestContext": {
    "httpMethod": "ANY",
    "identity": {},
    "path": "/my_hk",
    "serviceId": "service-aj0plx8u",
    "sourceIp": "136.49.211.114",
    "stage": "release"
  }
}

The Rust function parses the data in the body, performs PCA, and generates the SVG graph. It prints the SVG content to STDOUT, which is picked up by the API Gateway and sent back as the HTTP response.

To use this API Gateway URL in AJAX requests, you must also configure the Tencent Cloud gateway to accept CORS web requests. Check out this guide on how to do it.

The HTML JavaScript example below shows how to use this serverless function in a web page.

It takes the CSV data from the textarea field with ID csv_data, makes an AJAX HTTP POST request to the serverless function, and then puts the return value, which is a SVG graph, in an HTML element with ID svg_img. See the live demo here.

$.ajax({
  method: "POST",
  url: "https://service-m9pxktbc-1302315972.hk.apigw.tencentcs.com/release/PCASVG",
  data: $('#csv_data').val(),
  dataType: "text"
}).done(function(data) {
  $('#svg_img').html(data);
})

The serverless web application in action.

Next steps

The Tencent SCF Custom Runtime is a very powerful serverless environment. It provides a generic Linux environment for any application function you want to write, as well as standard web interfaces to interact with the function input and output. It is definitely worth trying out.

As discussed in the article, we believe that Rust and WebAssembly provides a high performance, safe, portable, and future-proof stack for serverless functions. Rust and WebAssembly with SCF Custom Runtime is the future!

Resources

• Learn more about why use WebAssembly on the server side

• Learn more about Tencent Serverless Cloud Functions

• Learn more about machine learning algorithms

• Getting started with Rust

• Machine learning algorithms in Rust and WebAssembly

• Getting started with Rust functions in Node.js

• Learn more about the Second State WebAssembly VM

Subscribe to our newsletter and stay in touch. Happy coding!

A gif showing the setup process of a GitHub Codespace

In the recent GitHub Satellite online conference, one of the most exciting product announcements was GitHub Codespaces. The idea is to have a code button on every repository.

When you click on it, it launches a fully featured VSCode IDE with all the necessarily software dependencies, including operating system level libraries, to build and run the project. This VSCode IDE runs entirely in your browser, and will not install any software or change any configuration to mess up your computer.

Sounds too good to be true? Well, watch the Github Satellite keynote segment about Codespaces yourself!

A key benefit of Github Codespaces is how quickly you can on-board new developers to a project. A new developer can get set up in minutes, instead of days, and immediately start contributing to the project. It is a great learning tool for new languages, frameworks, and software tools.

Under the hood, it starts a Docker container on a remote server, installs the entire software stack required by the project, and runs tasks like compiling and debugging in the remote Docker.

The web browser acts as a front end UI for the Docker instance. This approach requires no software install on the developer’s machine. But the trade-off is that all software installation from the operation system all the way to the final application happens on the server.

GitHub must start a fresh server for each Codespaces instance. That requires a lot of data center resources. In fact, the GitHub Codespaces web page has a waiting list as of today (June 2020).

Personally, I cannot wait for GitHub Codespaces to become available. But a time machine does exist. You can experience all the features in GitHub Codespaces today, for free.

VS Codespaces

The software behind GitHub Codespaces is actually based on a Microsoft VSCode product called VS Codespaces. VS Codespaces is available today to all Microsoft Azure users. And yes, it allows you to open GitHub repositories in VSCode IDE directly from a browser window.

In this tutorial, I will show you how to use Codespaces in your own development work today.

To make Codespaces available in your GitHub repositories, you just need to add the following HTML button anywhere on your web pages.

When an Azure user clicks on the button, it asks the user to log into VS Codespaces and walks the user through opening the repository in the online IDE. You can see how it works in the examples in the next section.

<p>
  <a href="https://online.visualstudio.com/environments/new?name=My%20Project&repo=username/reponame">
    <img src="https://img.shields.io/endpoint?style=social&url=https%3A%2F%2Faka.ms%2Fvso-badge">
  </a>
</p>

VS Codespaces runs entirely in your browser and costs around $1 per work day. It is cheaper than a cup of coffee in the office.

Examples

Now, let's look into several examples of how you might learn new programming skills using VS Codespaces.

Rust is one of the fastest growing programming languages today. It is voted as the most beloved programming language by Stackoverflow users four years in a row.

But to experiment with Rust requires a complex toolchain of compiler, linker, package manager, tool manager and so on.

VS Codespaces provides an easy way to learn Rust. Just click on the VS Codespaces button in this repository and you now have a working Rust project to experiment with!

https://github.com/second-state/learn-rust-with-github-actions

As a system language, Rust is well positioned to build high performance server side applications. The most promising stack is to compile and run Rust functions in a WebAssembly container, and then access those high performance functions from an existing web application framework, such as Node.js.

However, as you can already see, this “best practice” setup requires a complex stack of software.

Clicking on the VS Codespaces button in this repository gives you a fully functional Node.js project that uses Rust functions in WebAssembly as modules. You can immediately start to modify the Rust and JavaScript code and run the Node.js application from inside the web browser IDE.

https://github.com/second-state/ssvm-nodejs-starter

Server-side Rust and WebAssembly sound cool. But do we actually have a more complete example that demonstrate the power and performance of Rust beyond a simple hello world?

This repository is such an example. Open it in VS Codespaces and you will have a project for a Rust + JavaScript app that utilizes Tensorflow to perform image recognition. Since the app runs inside Node.js, it provides a template for AI-as-a-Service web applications.

https://github.com/second-state/rust-wasm-ai-demo

What if you want to stay on the bleeding edge and use Rust-based web runtime Deno instead of the C-based Node.js? Well, there is a VS Codespaces template for running Deno as an Azure Function too!

How it works

If you look closely, each VS Codespaces-enabled repository has a .devcontainer folder. Inside that folder, the Dockerfile specifies how to build the Docker container for the development environment.

For example, the Node.js Docker container is based on Ubuntu Linux with Node.js and selected NPM packages pre-installed. Check out an example here.

The devcontainer.json file specifies the configuration for the VSCode IDE on the remote Docker. For example, it configures the VSCode extensions to install, the terminal and debugger commands to use, and the host ports to forward to for testing and debugging.

Microsoft provides quite a few .devcontainer templates for you to modify and use. They cover most of the common software development stacks today.

You could further customize the user’s VSCode experience by providing launch and tasks definitions in the .vscode folder. Check them out!

Conclusion

With VS Codespaces, and GitHub Codespaces when it launches, the barriers and friction for software development are further reduced. You can get started with complex software stacks without leaving your web browser. Try it today!

Finally, watch the full length GitHub Satellite presentation on GitHub Codespaces.

Subscribe to my newsletter and stay in touch.

Rust is one of the hottest ? programming languages today. It is StackOverflow's most beloved programming language for the past 4 years. Yet, it still has a reputation as the programming language for alpha geeks.

By some estimate, there are 600,000 Rust developers world-wide, which is a significant number. But it's still dwarfed when compared with tens of millions of JavaScript, Java, and Python developers.

Who are those Rust developers? What are they using Rust for? Why do they love Rust so much? And most important, how do you join their ranks and see for yourself why Rust is so beloved? Don't get left behind.

In order to answer those questions, the Rust community has conducted annual developer surveys from rust-lang.org since 2016. The site recently released its 2019 survey results based on responses from nearly 4000 Rust developers. Here are the top 8 things I learned from the survey.

??‍? Rust is for professional programmers

The Rust programming language is not designed to be “easy to get started”. Rather, it is designed to be powerful and safe at the same time. It aims to be the developer productivity language for professional programmers. It is challenging, fun, and rewarding. That shows in the survey.

Very few respondents call themselves as Rust experts. Most people rate their Rust expertise as 7/10 or below, despite the fact that over 68% of them write Rust code on a weekly basis. It is clearly a language that takes time to master and excel.

About 37% of Rust users felt productive in Rust in less than a month of use - this is not too different from the percentage last year (40%). Over 70% felt productive in their first year. Unfortunately, like last year, there is still a struggle among users - 21% indicated they did not yet feel productive.

At the same time, when asked why not using Rust on some projects, the learning curve is cited as the #2 most common reason. The #1 reason, of course, is the company’s decision whether to use a particular programming language in a project.

? Documentation is critical for adoption

How do developers overcome Rust's learning curve and fall in love with it? Well, not unexpectedly, most developers cited “better documentation” as the driver for adoption.

But true to “professional programmers”, the most sought after Rust documentation is intermediate-level content that helps developers improve their Rust skills and productivity.

While the survey is biased toward developers who already knew the basics of Rust, it seems that there is a thirst for knowledge and self-improvement in this crowd.

? Developers do not want tomes of text

Traditional software documentation typically consists of entire books and websites. New generations of developers want more and better documentation. As a “new” language, Rust is already leading the innovation when it comes to programming language documentation.

For example, the Rust compiler is a self-documenting tool. One of the most unique and beloved features of Rust is its aggressive compiler that helps you ensure correctness and safety before the program even runs. As a result, Rust developers can write highly performant yet safe programs.

When you encounter a compiling error in Rust, the compiler gives you an immediate explanation of the error, and suggestions on how to fix the error based on the context of your program.

This starter project in GitHub gets you started with the Rust compiler and the Cargo system without having to install any software toolchain. You can use the VSCode online IDE directly with this project.

Rust documentation web sites like docs.rs and Rust by Example (and its Extended Edition) use the Rust Playground to run Rust example code directly from the browser. Those interactive books are much better than simple text.

However, as the survey finds out, developers want more. Developers are thirsty for more video content, for example. We can look forward to more coding videos and live broadcasts from the community soon.

?️ Most people use Rust for web apps, srsly!

As a system-level language intended to replace C and C++, most people assume that Rust would be used in infrastructure programming, such as operating systems, native libraries, and runtime platforms.

Yet, the survey clearly shows that by a large margin, most Rust developers today are working on web app backends. No wonder crates like hyper, actix-web, and Rocket are among the most popular with Rust developers.

To be sure, most software developers are working on web applications. It is not surprising that, as Rust gains mainstream adoption, Rust projects will mirror the bigger software industry.

However, that does present opportunities for projects and tools that integrates Rust into popular web application runtimes. For example, the Rust + JavaScript hybrid application approach is gaining momentum.

? Blockchain is a Rusty hotbed

When it comes to infrastructure software, Rust really shines as a programming language for blockchain systems.

For all software related industry sectors, the survey shows that blockchain only ranks the 35th for all software developers, but 11th for Rust developers. That is in no small part due to aggressive Rust adoption by large blockchain projects such as Polkadot / Substrate, Oasis, Solana, and Second State etc.

In many ways, blockchains are perfect fit for Rust. Blockchains represent the community effort to re-build the internet infrastructure in a decentralized manner. They require high performance software that is also very safe. If you are interested in a career as a blockchain engineer, Rust is a must-have skill today.

Rust ❤️ WebAssembly

The survey reveals that WebAssembly is a popular runtime environment for Rust programs. Rust and WebAssembly were both invented at Mozilla.

Rust is focused on performance and memory safety, while WebAssembly is focused on performance and runtime safety. As a runtime container, WebAssembly also makes Rust programs cross-platform and more manageable. There are indeed a lot of synergy between the two technologies.

WebAssembly was originally invented as a client side virtual machine to run in-browser applications. But as Java and JavaScript before it, WebAssembly is now making the migration from the client side to the server side.

Rust-in-WebAssembly bodes well with the trend of accelerating Rust adoption on backend web applications. You can get started with Rust and WebAssembly application development from a starter project in this GitHub repository.

? Asynchronous programming is taking off

In recent years, two new programming languages have gained significant traction among developers. One is Rust, and the other is Go. A big part of their success is their superior support for concurrency programming models.

In fact, an early tagline of Rust is "fearless concurrency". It promises developer productivity in writing asynchronous multi-threaded programs optimized for today’s multi-core CPU architectures. As Node.js demonstrated, easy asynchronous programming is crucial for a language or framework’s success on the server side.

The survey shows that 4 of the 10 most important Rust crates (ie third party libraries), tokio, async, futures, and hyper, are frameworks for asynchronous multi-thread applications.

? R, Python, and JavaScript

As the adoption of Rust grows, developers increasingly need to integrate Rust programs with programs written in other languages. In the past, C and C++ were the most common languages to “talk” to Rust as they are all used in infrastructure software projects.

As Rust grows into application software projects, more language level interfaces and bridges are needed now. A good example is the Rust JavaScript bridge that supports Rust functions in Node.js applications.

The survey found that, besides C/C++ and JavaScript, Rust developers are interested in integrating with R and Python. That indicates developer interests in machine learning, big data, and artificial intelligence (AI) applications. In fact, many Python and R machine learning and statistical packages are implemented in native binary modules.

Rust is one of the best programming languages to write native modules. This example shows how to use Rust to execute Tensorflow models in a Node.js application. In the future, we envision such Rust modules to run in high performance managed containers such as WebAssembly.

Conclusion

2019 was a year of growth and incremental improvements for Rust. As Rust becomes a mainstream programming language, we look forward to more documentation, more tools, more ecosystem support, more interoperability with other languages, and a gentler learning curve.

And most important of all, we are eager to make more friends and have fun with the most beloved programming language in the world!

About the author

Dr. Michael Yuan is the author of 5 books on software engineering. His latest book Building Blockchain Apps was published by Addison-Wesley in Dec 2019. Dr. Yuan is the co-founder of Second State, a VC-funded startup that brings WebAssembly and Rust technologies to cloud, blockchain, and AI applications. It enables developers to deploy fast, safe, portable, and serverless Rust functions on Node.js.

Prior to Second State, Dr. Yuan was a long time open source contributor at Red Hat, JBoss, and Mozilla. Outside of software, Dr. Yuan is a Principal Investigator at the National Institutes of Health, with multiple research awards on cancer and public health research. He holds a PhD in astrophysics from the University of Texas at Austin.

I love the web. It is a modern-day superpower for the dissemination of information and empowerment of the individual. Of course, it has its downsides like trolling (largely possible through anonymity) and privacy issues, not to mention the problems of ownership and copyright infringement about to come into effect with the highly divisive article 13. But, let’s forget about that for just a moment and marvel at the technological innovation of the internet and the browsers which support it.

I first learnt to code in Javascript and have since been ridiculed by many for liking it. Yes, I know there are weird bits like this gem: [] == ![] // true but it has become one of the most ubiquitous languages on the planet thanks to the internet, browsers and the interpreters that run the code (Google’s V8 and Firefox’s SpiderMonkey to name a few).

As I got more into web development, I noticed a new name on the block: WebAssembly. As a computer science student and a developer, I believe one of the best ways to learn something is to try and understand why the engineers who built it made those design choices. So here is a brief look at some of the interesting design principles in WebAssembly and also why I think everyone should be excited.

Why do we need WebAssembly?

Okay, so first of all, to all my Javascript fans out there — no you shouldn’t be worried. When Javascript first came about, it was designed to be used in a lightweight way but has since gone on to do a lot of heavy lifting. Maybe it was used for manipulating some DOM elements, some client-side verification in forms but not everything that is trying to be done on the web now. Certainly not running fully-fledged games.

Why is Javascript not so fast or great? One of the main reasons is because it is an interpreted language. Scanning the code line by line and executing, luckily with Just-in-Time compilers, the efficiency improved massively but still there is only so much room to improve. But even then there’s the issue of Javascript’s dynamic typing causing another ceiling on performance

Alex Danilo discussed the improvements WebAssembly could make in his Google I/O talk in 2017. What really brought home the inefficiencies was his example add(a, b) function and the complexity that the Javascript interpreters have to go through in order to make sense of it.

_A simple Javascript function — [ECMAScript Rabbit Hole p.263](https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf" rel="noopener" target="blank" title=") (be sure to follow the links of the other function calls)

WebAssembly opens the door to compilation, which opens another door to optimisation. It’s ability to take C/C++ source language allows it to do some static type checking which helps improve speed. This is what the developers of the Mozilla Foundation realised and wanted to fix. To summarise this great video, Javascript was designed for humans and browsers were left to try and make it fast; WebAssembly was designed as a target language for compilers that browsers could already run quickly.

The realisation that we could have two choices of code run in the engines was an exciting prospect — and the four major browsers (Chrome, Safari, Firefox and IE) all began plans to let their engines run Javascript and WebAssembly. Again, let me reiterate… WebAssembly is not replacing Javascript.

Why compile code?

Compiling code really means taking it from one (source) language and translating it into another (target) language. This is an incredibly simplified understanding of compilation. Most modern day compilation pipelines involve many more stages that allow us to really fine-tune and optimise our code making it faster and more energy-efficient.

The first steps usually include lexical, syntactic and semantic analysers to get the code into some kind of intermediate language that is perfect for optimisation. Then we optimise independently, generate the target code and then maybe optimise dependently on the hardware or environment.

All projects need to start small first, and the engineers at Mozilla decided to begin with their source language being C/C++ and using an existing toolchain called LLVM (not an acronym) they would compile using that.

Initially, the search for a better performing web started with [asm.js](http://asmjs.org/spec/latest/) (at least in WebAssembly narrative. See PNaCL — Google’s earlier attempts) a small subset of Javascript that could be the compile target for C/C++ programs that used annotations and other clever tricks to improve the Javascript performance.

Unfortunately, it lacked one crucial design principle underlying what was wanted: Portability. Different Javascript engines gave different performance reviews, but it was a clear indication that this may be a good approach.

The developers of WebAssembly decided their target representation would be a binary format that provided a “dense, linear encoding of the abstract syntax”… Which is a lot of words, so let’s unpack that.

The “dense” part refers to the high-level goal of achieving a size and load time efficient format. The internet is all about sending data along wires, and whilst there are lots of projects to improve the latency of this, one foolproof way of achieving this is to send less data. Another important aspect is the increased decoding speed thanks to array indexing over dictionary lookup (if they used compressed text format). Read more about this design choice here.

What is wat?

The binary format that the C and C++ programs compile to are .wasm files, these have a 1:1 mapping straight to a (somewhat) human readable text format. These files are labelled .wat , this WasmExplorer is great for getting your head around text representation and how it relates to the original code. Let’s take a simple example.

There’s a lot going on here so let’s take it slowly and explain the concepts as they come.

First, there is this weird module word, where did that come from? Mejin Leechor gave a great talk on modules in Javascript and describes them as giving code “structure and boundaries”. This is very similar to the idea of WebAssembly modules (and there are plans in the future to try and integrate with es6 modules).

Straight from the docs, we have that the module is the “distributable, loadable, and executable unit of code in WebAssembly”. Modules can have the following sections each with their own unique responsibility: import, export, start, global, memory, data, table, elements, function and code. For now, let’s just look at what we have in our module.

The first declaration is (type $type0 (func (param i32) (result i32))) . This is intimately linked to the table call on the next line. We are declaring a new type with the func signature that takes a 32 bit integer parameter and returns a 32 bit integer. If we were to make use of the function we wrote again, we would have to make a call_indirect into our table and then we could do some type-checking to make sure everything was correct. As part of the minimal viable product only one table is allowed, but there are future plans to allow multiple tables and for these to be indexed.

The next declaration is (table 0 anyfunc) . The table section is reserved for defining zero or more tables. A table is similar to a linear memory in the sense that they are resizable arrays which contain references. The 0 makes reference to the fact that we have nothing in our table, but we still need to provide the MVP’s only possible value of anyfunc (a function).

The problem that the developers had was linked to security. If a function wanted to call another function, giving it direct access to a function stored in linear memory was unsafe. Instead functions are stored in the table ready to be indexed if needed. Lin Clark wrote a great article describing tables (as used in imports) in more detail and how they provide better security.

We then have a declaration of (memory 1) , this is the linear memory used by the module and we declare that we need 1 page of memory (64KiB).

The next declaration is (export "memory" memory) . An export is something that is returned to the host at instantiation time. Basically, the cool bits we want from the WebAssembly code.

The structure is quite simple (export <name-of-export> (<type> &lt;name/index>)) so here we are just exporting the memory we declared in the previous line. This allows for direct memory access within our Javascript code, as an ArrayBuffer which drastically improves the efficiency as there are no backwards and forwards calls across the WASM/JS border. Similarly we then export our function with (export "main" $func0) .

Now to the slightly more interesting bit, our code and its representation.

The different parts of the function declaration in WebAssembly Text Format

Before moving on, this is the perfect opportunity to introduce yet another design component: the stack machine.

Register versus Stack Machines

Computers, at their simplest, consume inputs and produce outputs. As a ‘machine’ executes a program it can do so in multiple different ways. Two of the main approaches are register and stack machines. In a register machine, parameters to functions are kept in memory locations and are then manipulated depending on the program in execution.

A simple, but somewhat flawed, analogy could be a kitchen and making a recipe. The ingredients are stored in different locations, you get them and make something which you might put somewhere for another day or immediately consume (yum). It’s far from perfect but hopefully you get the idea.

Stack machines, on the other hand, employ a different model. Imagine you are a journalist or secretary, your job is to read and respond to letters. You ‘pop’ the top letter from your pile and begin writing a response whilst someone else comes along with more work and ‘pushes’ to the top of the pile. These are the ones you are going to have to do next. Again, grossly oversimplified but it should help visualise the mechanics.

WebAssembly uses a stack machine model for code execution. If you’re short of some great reading, and are into programming semantics, the paper “Bringing the Web up to Speed with WebAssembly” is really good. It also indicates why they choose the stack machine representation: “The stack organization is merely a way to achieve a compact program representation, as it has been shown to be smaller than a register machine” with reference to this paper which found “… the bytecode size of the register machine being only 26% larger than that of the corresponding stack one”.

Even though the stack machine approach isn’t necessarily faster, it offered smaller bytecode; an incredibly important design goal for internet-based transactions.

So how can we understand the text-format as a stack machine. As we read the code line by line we end up pushing arguments to the stack, then popping them off, doing some computation and pushing the result back. And repeat.

A small example of WebAssembly and the implicit stack machine approach

At first it might seem a little odd to have a text format, if in the end it will be compiled to the binary format for compression. But, the internet has always had the policy of viewing the source and that’s why the developers behind WebAssembly produced the text format. To go one step further and avoid conflicts of syntax they used the Lisp-like s-expression style.

Safety and Sandboxing

One of the greatest sources of bugs (and exploits) in unsafe languages is buffer overflows. C and C++ are almost interchangeable with this idea and it is one of the first aspects you are taught when learning these languages. In exchange for a little overhead costs, WebAssembly adds this safety net by enforcing fixed-sized, indexed memory (although certain memory can be grown).

The local variables to our function, for example$var0 , are not referenced by address but instead are indexed providing a layer of security. Access is granted via the get_local and set_local commands which all happens within the index space of the local variables.

Memory security was a top priority when designing WebAssembly. Straight from the documentation: “Linear memory is sandboxed; it does not alias other linear memories, the execution engine’s internal data structures, the execution stack, local variables, or other process memory.” Lin Clark, again, wrote a great article describing this.

The basic idea is comparable to the Javascript ArrayBuffer object — resizable and bound-checked. What we’re trying to achieve is program isolation to prevent errors and malicious code from spreading and corrupting data it shouldn’t even have access to.

What can WebAssembly do?

One of the major end-goals for WebAssembly was revolutionising what was possible in terms of graphics on the web. The classic examples are ZenGarden by EpicGames and Tanks!.

Thanks to its design, WebAssembly marks a pivotal moment in web development. The internet has a new tool in its arsenal to create amazing experiences and share information. WebAssembly provides smaller code-sizes, faster execution, greater security and a lot of room for extensibility. With ideas like threads, single-instruction multiple-data (SIMD) primitives and zero-cost execution on the horizon, WebAssembly’s abilities look only set to expand.

Go 1.11 hit the ground on 24 August 2018. It introduces a few really needed tools and components such as versioned modules, WebAssembly support, and debugging improvements. It also brings some changes to core packages and performance/run-time.

As always, the release maintains the Go 1 promise of compatibility. So almost all Go programs continue to compile and run as before with this update. There are no changes to the language specification.

Let’s take a look at what’s new.

Modules

Go 1.11 includes experimental support for Go modules, including a new module-aware go get command.

The quickest way to take advantage of the new module support is to check out your repository into a directory outside, create a go.mod file and run Go commands from within that file tree.

Let’s demo this. I am using the testify-powerful and standard Go testing libraries.

Let’s clone the testify repo in my favorite folder ~/proj/github .

$ git clone https://github.com/stretchr/testify ~/proj/github/testify$ cd ~/proj/github/testify

Now, to use Go commands from here, you need to initialize this repo as a module with the following command:

go mod init github.com/stretchr/testify

Where github.com/stretchr/testify is the location you would generally put this repo, under the Go src folder.

This command will create a go.mod file in the root of the folder. In a project already using an existing dependency management tool like godep, glide, or dep, go mod init will also add require statements matching the existing configuration.

Now if you open the go.mod file, you can see the list of dependencies with the module name.

$ vi go.mod

module github.com/stretchr/testify

require (    github.com/davecgh/go-spew v1.1.0    github.com/pmezard/go-difflib v1.0.0    github.com/stretchr/objx v0.1.0)

As you’ll notice, these three are the dependencies of the testify. This is testify’s Gopkg.toml file:

[prune] unused-packages = true non-go = true go-tests = true

[[constraint]] name = “github.com/davecgh/go-spew” version = “~1.1.0”

[[constraint]] name = “github.com/pmezard/go-difflib” version = “~1.0.0”

[[constraint]] name = “github.com/stretchr/objx” version = “~0.1.0”

Now that the module has been initialized, you can use any Go command from this folder.

╭─ ~/proj/github/testify  ‹master*› ╰─$ go build                               go: finding github.com/davecgh/go-spew v1.1.0go: finding github.com/pmezard/go-difflib v1.0.0go: finding github.com/stretchr/objx v0.1.0go: downloading github.com/davecgh/go-spew v1.1.0go: downloading github.com/pmezard/go-difflib v1.0.0go: downloading github.com/stretchr/objx v0.1.0

╭─ ~/proj/github/testify  ‹master*› ╰─$ go test PASSok   github.com/stretchr/testify 0.001s

So with Go 1.11 and modules, you can write your Go modules anywhere you like and you don’t need to maintain a copy in a specific sub directory of your $GOPATH.

WebAssembly

Go 1.11 adds an experimental port to WebAssembly.

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

Now we can run Go in the browser, and vice versa — we can run JavaScript in Go easily. Although this feature is in the experimental state, it’s still pretty useful.

This small example calls Go from the Web:

wasm-exec.html

<!doctype html><!--Copyright 2018 The Go Authors. All rights reserved.Use of this source code is governed by a BSD-stylelicense that can be found in the LICENSE file.--><html>

<head>    <meta charset="utf-8">    <title>Go wasm</title></head>

<body>    <script src="wasm_exec.js"></script>    <script>        if (!WebAssembly.instantiateStreaming) { // polyfill            WebAssembly.instantiateStreaming = async (resp, importObject) => {                const source = await (await resp).arrayBuffer();                return await WebAssembly.instantiate(source, importObject);            };        }        const go = new Go();        let mod, inst;        WebAssembly.instantiateStreaming(fetch("test.wasm"), go.importObject).then((result) => {            mod = result.module;            inst = result.instance;            document.getElementById("runButton").disabled = false;        });        let printMessage // Our reference to the Go callback        let printMessageReceived // Our promise        let resolvePrintMessageReceived // Our promise resolver        function setPrintMessage(callback) {          printMessage = callback          resolvePrintMessageReceived()        }        async function run() {          console.clear()          // Create the Promise and store its resolve function          printMessageReceived = new Promise(resolve => {            resolvePrintMessageReceived = resolve          })          const run = go.run(inst) // Start the wasm binary          await printMessageReceived // Wait for the callback reception          printMessage('Hello Wasm!') // Invoke the callback          await run // Wait for the binary to terminate          inst = await WebAssembly.instantiate(mod, go.importObject) // reset instance        }    </script>

<button onClick="run();" id="runButton" disabled>Run</button></body>

</html>

go-call.go

package main

import (  "fmt"  "syscall/js")

var done = make(chan struct{})

func main() {  callback := js.NewCallback(printMessage)  defer callback.Release() // To defer the callback releasing is a good practice  setPrintMessage := js.Global().Get("setPrintMessage")  setPrintMessage.Invoke(callback)  <-done}

func printMessage(args []js.Value) {  message := args[0].String()  fmt.Println(message)  done <- struct{}{} // Notify printMessage has been called}

You can find more examples here. And here is a video on building a calculator with WebAssembly.

Other changes to consider

• Because Go module support assigns special meaning to the @ symbol in command line operations, the gocommand now disallows the use of import paths containing @ symbols.
• With the new runtime/trace package's user annotation API, users can record application-level information in execution traces and create groups of related goroutines. The go tool trace command visualizes this information in the trace view and the new user task/region analysis page.
• The runtime now uses a sparse heap layout so there is no longer a limit to the size of the Go heap (previously, the limit was 512GiB). This also fixes rare “address space conflict” failures in mixed Go/C binaries or binaries compiled with -race.
• time: Parsing of timezones denoted by sign and offset is now supported. In previous versions, numeric timezone names (such as +03) were not considered valid, and only three-letter abbreviations (such as MST) were accepted when expecting a timezone name.
• text/scanner: The [Scanner.Scan](https://golang.org/pkg/text/scanner/#Scanner.Scan) method now returns the [RawString](https://golang.org/pkg/text/scanner/#RawString) token instead of [String](https://golang.org/pkg/text/scanner/#String) for raw string literals.
• There are changes in crypto, encoding, net/http, os, runtime, sync, mime and few others which you can read about here.

If you enjoyed this article, spare me some claps — it means the world to the writer. Follow me if you want to read more articles about Go, JavaScript, Technology, and Startups.

WebAssembly is blazing fast for number crunching, game engines, and many other things, but nothing can quite compare to the extreme parallelization of shaders, running on the GPU.

This is especially so if you’re looking to do some image processing. Usually, on the web, this is done through WebGL, but how would you access its APIs when using WebAssembly?

Setting up

We’ll very briefly go through setting up an example project, then we’ll look at how an image can be loaded as a texture. Then, in a separate context, we’ll apply an edge detection GLSL shader to the image.

All the code is in a repo here, if you’d prefer to jump straight to that. Note that you have to serve your files via a server for WebAssembly to work.

As a prerequisite, I’m going to assume you already have your WebAssembly project set up. If not, you can check out the article here on how to do it, or just fork the repo linked above.

For demoing the below code, I’m using a basic html file which serves only to load an image, get its imageData, and pass it to the WebAssembly code using the ccallArrays function.

The HTML file with the preview input image

As for the C++ code, there is an emscripten.cpp file which manages and routes method calls to context instances created in the Context.cpp file. The Context.cpp file is structured as follows:

Compilation

WebGL is based on and follows the OpenGL ES (Embedded Systems) spec, which is a subset of OpenGL. When compiling, emscripten will map our code to the WebGL API.

There are a couple of different versions we can target. OpenGL ES 2 maps to WebGL 1, whereas OpenGL ES 3 maps to WebGL 2. By default you should target WebGL 2, as it comes with some free optimizations and improvements.

To do this, we must add the USE_WEBGL2=1 flag to the compilation.

If you are planning to use some OpenGL ES features not present in the WebGL spec, you can use the FULL_ES2=1 and/or FULL_ES3=1 flags.

To be able to handle large textures/images, we can also add the ALLLOW_MEMORY_GROWTH=1 flag. This removes the memory limit of the WebAssembly program, at the cost of some optimizations.

If you know ahead of time how much memory you’ll need, you can instead use the TOTAL_MEMORY=X flag, where X is the memory size.

So we’re going to end up with something like this:

emcc -o ./dist/appWASM.js ./dev/cpp/emscripten.cpp -O3 -s ALLOW_MEMORY_GROWTH=1 -s USE_WEBGL2=1 -s FULL_ES3=1 -s WASM=1 -s NO_EXIT_RUNTIME=1 -std=c++1z

Finally, we need the following imports, in our code:

#include <emscripten.h>#include <string>#include <GLES2/gl2.h>#include <EGL/egl.h>extern "C" {       #include "html5.h" // emscripten module}

Implementation

If you have previous experience with WebGL or OpenGL, then this bit may seem familiar.

When writing OpenGL, the API will not work until you create a context. This is normally done using platform specific APIs. However, the web is not platform bound, and we can instead use an API integrated into OpenGL ES.

The majority of the legwork, however, can be more easily implemented using emscripten’s APIs in the html5.h file. The functions we’re interested in are:

• _emscripten_webgl_createcontext — This will instantiate a context for the given canvas and attributes
• _emscripten_webgl_destroycontext — This is needed for cleaning up memory when destructing context instances
• _emscripten_webgl_make_contextcurrent — This will assign and switch which context WebGL will render to

Create the context

To start implementing, you have to first create the canvas elements in your JavaScript code. Then, when using the emscripten_webgl_create_context function, you pass the id of the canvas as the first parameter, with any configurations as the second. The emscripten_webgl_make_context_current function is used to set the new context as the one currently in use.

Next, the vertex shader (to specify coordinates) and the fragment shader (to calculate the colour at each pixel) are both compiled, and the program is built.

Finally, the shaders are attached to the program, which is then linked, and validated.

Though that sounds like a lot, the code for this is as follows:

The shader compilation is done within the CompileShader helper function which performs the compilation, printing out any errors:

Create the shader

The shader code for this example is minimal, and it just maps each pixel to itself, to display the image as a texture:

You can access the canvas’ context in JavaScript in addition to the context in the C++ code, but it must be of the same type, ‘webgl2’. While defining multiple context types does nothing when just using JavaScript, if you do it before creating the webgl2 context in WebAssembly, it will throw an error when the code execution gets there.

Loading the texture

The first thing to do when applying the shader is to call the emscripten_webgl_make_context_currentfunction to make sure that we are still using the correct context, and glUseProgramto make sure we are using the correct program.

Next, we get the indices of the GLSL variables (similar to getting a pointer) via theglGetAttribLocationand glGetUniformLocation functions, so we can assign our own values to those locations. The function used to do that depends on the value type.

For example, an integer, such as the texture location needs glUniform1i, whereas a float would need glUniform1f. This is a good resource for seeing which function you need to use.

Next, we get the texture object via glGenTextures, assign it as the active texture, and load the imageData buffer. The vertex and indices buffers are then bound, to set the boundaries of the texture to fill the canvas.

Finally, we clear the existing content, define our remaining variables with data, and draw to the canvas.

The texture being loaded

Detect edges using a shader

To add another context, where the edge detection is done, we load a different fragment shader (which applies the Sobel filter), and we bind the width and height as extra variables, in the code.

To pick between different fragment shaders, for the different contexts, we just add an if-else statement in the constructor, like so:

And to load the width and height variables, we add the following to the run function:

If you run into an error similar toERROR: GL_INVALID_OPERATION : glUniform1i: wrong uniform function for type, then there’s a mismatched assignment function for the given variable.

One thing to look out for when sending the imageData, is to use the correct heap, unsigned integer (the Uint8Array typed array). You can learn more about those here, but if you’re using the ccallArray function, set the ‘heapIn’ config to “HEAPU8”, as seen above.

If the type is not correct, the texture will still load, but you’re going to be seeing strange renderings, like these:

Conclusion

We’ve gone through a mini “Hello World!”-style project to show how to load textures and apply GLSL shaders to them in WebAssembly. The complete code is hosted on GitHub here, for further reference.

For a real project, you may want to add some additional error handling. I omitted it here, for clarity.

It may also be more efficient (in the above example) to share data such as the imageData texture between contexts. You can read more about this and more here.

For some further reading, you can check out this link for common mistakes, or you can look through some demo projects in emscripten’s glbook folder, on GitHub.

To see WebGL being used in a WebAssembly project, you can check out the dev branch on jsNet, a web based deep learning framework, where I’ll be working on moving heavier computations onto shaders, over the next few weeks (support for WebGL compute shaders via OpenGL ES 3.1 can’t come soon enough ? ).

Update

To see what GPU compute using shaders would look like in WebAssembly, you can check out the repo for GPGPU, a small library I’m working on, with both JavaScript and WebAssembly versions.