embedded-scripting-languages VS wasmer-go

Hopefully the linked README provides a general overview (I know I need to write some more documentation!), but Steel is an implementation of the scheme programming language (not entirely compliant yet, but aiming for R5RS and R7RS compliance). It can be used as a standalone language via the interpreter/repl (like Python or Racket), or it can be embedded inside applications, like Lua. There are hundreds (thousands, probably) of embeddable languages, each with their own flavor - see a list compiled here for example https://github.com/dbohdan/embedded-scripting-languages

Use cases are generally for either configuration, scripting, or plugins - so scripting in games, or adding extensions to your text editor without having to use FFI or RPC + serializing a bunch of data. The advantage it has over using dynamic libraries (in general) is it runs in the same process, and can access the internal data structures directly without a lot of ceremony involved. The downside is typically is not as fast as native code unless a JIT is involved.

Javascript is an example of an embedded scripting, where the browser is the host application.

> There is a huge opportunity, IMO, for more players here.

There are quite a few embeddable scripting languages [1]. I think these days it's less common to embed a language mostly because there are good high-level languages that applications can be predominantly written in.

[1] https://github.com/dbohdan/embedded-scripting-languages

I'm not a huge fan of Lua but I think it is at least way more popular and better on every measure than TCL. There are plenty of other better less well-known options too: Rhai, Wren, AngelScript, Starlark (for some use cases), etc. There's a good list here.

or perhaps use one of this list (depending on who's writing the configuration): https://github.com/dbohdan/embedded-scripting-languages

https://github.com/dbohdan/embedded-scripting-languages (coincidentally, from a user whose name I recognize from the Tcl wiki)

The next step is to create a Go project and run our wasm file with some runtime. For this, I chose wasmer-go.

However, there are other, more fleshed-out, libraries like wasmer-go that provides a runtime and help us navigate around these limitations. The wasmer-go documentation provides a good summary of these challenges:

wasmer-go

I did some research and found a WebAssembly runtime that can run Go code that has been compiled to WASM. It seems to me that one could implement a plugin system using this. I might try.

Thank you Syrus, appreciate your work with Wasmer. Congrats on the 3.0 release and Windows support! I just fixed guregu/trealla on WAPM to work with the latest changes. I think WAPM is very cool and I hope more people start doing releases on it.

These are the two issues I'm referring to:

https://github.com/wasmerio/wasmer-go/pull/200

https://github.com/wasmerio/wasmer-go/pull/286

Time to implement the other side of the story. I have found a WebAssembly runtime for Go. Wasmer-go is a complete and mature WebAssembly runtime for Go based on Wasmer.

If performance is your main concern, there's Wasmer-go, but if you'd rather avoid CGO dependencies, there's wazero.

See wasmer-go for server-side runtime.

I've been looking at wasmer-go, and it seems to be quite performant given that the runtime is written in Rust and invoked through CGo bindings. Is this what everyone is using?

Go: I don't know of anything higher-level than either exposing a C ABI from Rust and then calling it using cgo or using wasmer-go to embed a WebAssembly runtime in your Go program.