Development / Kubernetes / Serverless

WebAssembly Developers Lust for Rust and AssemblyScript (But Not Go)

24 Jun 2021 11:53am, by

WebAssembly (WASM) has captured everybody’s attention because it allows developers to write code in their high-level language of choice and is platform agnostic. The recently released The State of WebAssembly 2021 shows that Rust is far and away that choice, but what other languages will be used by the next generation of WASM development?

According to a 249-person poll by the WebAssembly Weekly newsletter and its broader community, 69% of WASM developers have some experience using Rust for WebAssembly development. Some combinations of C++ or Emscripten are utilized by 51% of those surveyed, followed by 35% using AssemblyScript, a language created for WASM that compiles a variant of TypeScript. About half the survey had more than two years of experience using WASM.

Going forward, Rust does even better — 60% want to use it a lot for WASM development and another 18% plan to use it to some extent in the future. AssemblyScript surpasses the other languages with 56% of respondents having some plans for it. AssemblyScript is interesting because of the big names that are sponsoring the project, which includes Fastly and Shopify as well as groups like NEAR, ChainSafe, and The Graph that are involved with some of the best known involved with some of the best know decentralized protocols.

The uptake of other languages has not been as strong. For example, while 20% have used Go or TinyGo, 67% are not including the language in their future plans. There does not appear too strong an opposition to Go, just more familiarity with other languages. A few months ago, we posted Rust vs. Go: Why They’re Better Together, which explains the trade-offs. The recent launch of Krustlets is a positive sign that more Go developers will integrate applications into the WASM ecosystem.

Only 26% of these developers believe WASM really needs to improve the breadth of languages it supports to be successful in the future. As Scott Logic’s Colin Eberhardt explained in the report’s write-up, the focus is not on adding new languages to compile to WASM, but instead improving the developer experience for existing ones. Twice as many (56%) said better debugging support is really needed, something that , Sentry‘s Director of Engineering explained to our readers.

If the developer experience improves, there is also a good chance the current batch of Rust developers will see their party crashed. When that happens, they will find developers that understand the backend more than the frontend, which may give new life to C# developers that can compile using Blazor. The same may happen for other “legacy” languages with large ecosystems of existing applications that can be re-packaged into VMs, containers and other modules.

For now, we know that 73% of respondents currently use WASM for web development, which is almost two times as many as the next leading use case. WebAssembly is used for game development by 27%, for serverless by 24% and containers by 21%. Only 8% use it for either blockchain or cryptography, which indicates that Ethereum and Dapp roadmaps are far ahead of a vast mass of developers who are still just thinking about learning about how to program smart contracts.

Source: The State of WebAssembly 2021. Only 20% have used Go or TinyGo, 17% have used C# or its compiler Blazor, which is C# native, and even fewer have experience with other languages. Per the actual wording in the survey, this charts’ C++ label should read “C++ / Emscripten”; Blazor should read “Blazor / C#”; and Go should read “Go / TinyGo”.

Source: There is an opportunity for vendors to offer services to developers looking to run workloads using WASM but who do not want to learn backend skills. For example, 24% believe their front-end abilities can best be described as being able to work on codebases using modern frameworks (e.g., React, Vue).  The State of WebAssembly 2021.

Feature image via Pixabay.

Participate in The New Stack surveys and be the first to receive the results of our original research.