Research: WASM as a Lua alternative and for dynamically loadable modules
- A Lua alternative: matching and outputs (where Lua is used)
- As a module format for dynamically loadable modules/plugins
- WASM modules run in a very restrictive execution environment where they cannot access the network, files, etc.
- This might be OK for pure algorithmic uses, such as a module that calculates entropy.
- But is not suitable if the module requires access to external files, either to read in data from an external source (for example in a Lua rule), or writing to a custom log file (a Lua output).
- WASM also requires more overhead on the authors part. Once they have chosen a lanuage, they will have to configure their toolchain to output WASM. While in some cases this may be trivial, it is more overhead than writing a Lua script.
- WASM may be more interesting for dynamically loadable modules, but its restricted environment may not make that very popular.
- From my understanding it would not be possible to implement a custom database or Kakfa style output as a WASM module. However I could be wrong as I've seen examples of Nginx recompiled to WASM, so more research is required here.
- Its restrictions may make it not popular as a format for dynamically loadable modules, however the strict environment it runs in would be nice. But writing native plugins and loading as a .so will ultimately be more flexible (but not sandboxed).
WASM outside of the browser also appears to be very young and rapidly evolving.
I also found AssemblyScript (https://github.com/AssemblyScript/assemblyscript) interesting. This is a compiler for a subset of TypeScript that compiles to WASM.