wa-lang.org/wazero@v1.0.2/site/content/languages/_index.md (about)

     1  +++
     2  title = "Languages"
     3  layout = "single"
     4  +++
     5  
     6  WebAssembly has a virtual machine architecture where the host is the embedding
     7  process and the guest is a program compiled into the WebAssembly Binary Format,
     8  also known as Wasm. The first step is to take a source file and compile it into
     9  the Wasm bytecode.
    10  
    11  e.g. If your source is in Go, you might compile it with TinyGo.
    12  ```goat
    13      .-----------.    .----------------------.      .-----------.
    14     /  main.go  /---->|  tinygo -target=wasi +---->/ main.wasm /
    15    '-----+-----'      '----------------------'    '-----------'
    16  ```
    17  
    18  Below are notes wazero contributed so far, in alphabetical order by language.
    19  
    20  * [Go](go) e.g. `GOARCH=wasm GOOS=js go build -o X.wasm X.go`
    21  * [TinyGo](tinygo) e.g. `tinygo build -o X.wasm -target=wasi X.go`
    22  * [Rust](rust) e.g. `rustc -o X.wasm --target wasm32-wasi X.rs`
    23  
    24  wazero is a runtime that embeds in Go applications, not a web browser. As
    25  such, these notes bias towards backend use of WebAssembly, not browser use.
    26  
    27  Disclaimer: These are not official documentation, nor represent the teams who
    28  maintain language compilers. If you see any errors, please help [maintain][1]
    29  these and [star our GitHub repository][2] if they are helpful. Together, we can
    30  make WebAssembly easier on the next person.
    31  
    32  ## Constraints
    33  
    34  The [WebAssembly Core specification]({{< ref "/specs#core" >}}) defines a
    35  stack-based virtual machine. The only features that work by default are
    36  computational in nature, and the only way to communicate is via functions,
    37  memory or global variables.
    38  
    39  WebAssembly has no standard library or system call interface to implement
    40  features the operating system would otherwise provide. Certain capabilities,
    41  such as forking a process, will not work. Support of common I/O features, such
    42  as writing to the console, vary. See [System Calls](#system-calls) for more.
    43  
    44  Software is more than technical constraints. WebAssembly remains a relatively
    45  niche target, with limited maintenance and development. This means that certain
    46  features may not work, yet, even if they could technically.
    47  
    48  In general, developing with WebAssembly is difficult, and fewer problems can
    49  be discovered at compilation time vs more supported targets. This results in
    50  more runtime errors, or even panics. Where error messages exist, they may be
    51  misleading. Finally, the languages maintainers may be less familiar with how to
    52  solve the problems, and/or rely on less available key maintainers.
    53  
    54  ### Mitigating Constraints
    55  
    56  The above constraints affect the library design and dependency choices in your
    57  source, and by extension the choices of library dependencies you can use. In
    58  extreme cases, constraints or support concerns may lead developers to choose
    59  newer languages like [Zig][10].
    60  
    61  Regardless of the programming language used, the best advice is to unit test
    62  your code, and run tests with your intended WebAssembly runtime, like wazero.
    63  
    64  These tests should cover the critical paths of your code, including errors.
    65  Doing so protects your time. You'll have higher confidence, and more efficient
    66  means to communicate problems vs ad-hoc reports.
    67  
    68  ## System Calls
    69  
    70  WebAssembly is a stack-based virtual machine specification, so operates at a
    71  lower level than an operating system. For functionality the operating system
    72  would otherwise provide, system interfaces are needed.
    73  
    74  Programming languages usually include a standard library, with features that
    75  require I/O, such as writing to the console. Portability is helped along with
    76  [POSIX][3] conforming implementations of system calls, such as `fd_read`.
    77  
    78  There is a [WebAssembly System Interface]({{< ref "/specs#wasi" >}}), a.k.a.
    79  WASI, which defines host functions loosely based on POSIX. There's also a
    80  de facto implementation [wasi-libc][4]. However, WASI is not a standard and
    81  language compilers don't always support it.
    82  
    83  For example, AssemblyScript once supported WASI, but no longer does. Even
    84  compilers that target WASI using [wasi-libc][4] have gaps. For example,
    85  [TinyGo](tinygo) does not yet support `fd_readdir`. Some toolchains have a
    86  hybrid approach. For example, Emscripten uses WASI for console output, but its
    87  own virtual filesystem functions. Finally, the team behind WASI are
    88  developing an incompatible, modular replacement to the current version.
    89  
    90  It is important to note that even when system interfaces are supported, some
    91  users prefer a freestanding compilation target that restricts them. This helps
    92  them control binary size and performance.
    93  
    94  In summary, system interfaces in WebAssembly are not standard and are immature.
    95  Developers need to understand and test the system interfaces they rely on.
    96  Testing ensures not only the present capabilities, but also they continue to
    97  operate as the ecosystem matures.
    98  
    99  ## Concurrency
   100  
   101  WebAssembly does not yet support true parallelism; it lacks support for
   102  multiple threads, atomics, and memory barriers. (It may someday; See
   103  the [threads proposal][5].)
   104  
   105  For example, a compiler targeting [WASI]({{< ref "/specs#wasi" >}}), generates
   106  a `_start` function corresponding to `main` in the original source code. When
   107  the WebAssembly runtime calls `_start`, it remains on the same thread of
   108  execution until that function completes.
   109  
   110  Concretely, if using wazero, a Wasm function call remains on the calling
   111  goroutine until it completes.
   112  
   113  In summary, while true that host functions can do anything, including launch
   114  processes, Wasm binaries compliant with the [WebAssembly Core Specification]
   115  ({{< ref "/specs#core" >}}) cannot do anything in parallel, unless they use
   116  non-standard instructions or conventions not yet defined by the specification.
   117  
   118  ### Compiling Parallel Code to Serial Wasm
   119  
   120  Until this [changes][5], language compilers cannot generate Wasm that can
   121  control scheduling within a function or safely modify memory in parallel.
   122  In other words, one function cannot do anything in parallel.
   123  
   124  This impacts how programming language primitives translate to Wasm:
   125  
   126  * Garbage collection invokes on the runtime host's calling thread instead of
   127    in the background.
   128  * Language-defined threads or co-routines fail compilation or are limited to
   129    sequential processing.
   130  * Locks and barriers fail compilation or are implemented unsafely.
   131  * Async functions including I/O execute sequentially.
   132  
   133  Language compilers often used shared infrastructure, such as [LLVM][6] and
   134  [Binaryen][7]. One tool that helps in translation is Binaryen's [Asyncify][8],
   135  which lets a language support synchronous operations in an async manner.
   136  
   137  ### Concurrency via Orchestration
   138  
   139  To work around lack of concurrency at the WebAssembly Core abstraction, tools
   140  often orchestrate pools of workers, and ensure a module in that pool is only
   141  used sequentially.
   142  
   143  For example, [waPC][9] provides a WASM module pool, so host callbacks can be
   144  invoked in parallel, despite not being able to share memory.
   145  
   146  [1]: https://github.com/tetratelabs/wazero/tree/main/site/content/languages
   147  [2]: https://github.com/tetratelabs/wazero/stargazers
   148  [3]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/contents.html
   149  [4]: https://github.com/WebAssembly/wasi-libc
   150  [5]: https://github.com/WebAssembly/threads
   151  [6]: https://llvm.org
   152  [7]: https://github.com/WebAssembly/binaryen
   153  [8]: https://github.com/WebAssembly/binaryen/blob/main/src/passes/Asyncify.cpp
   154  [9]: https://github.com/wapc/wapc-go
   155  [10]: https://ziglang.org/