embedded-scripting-languages VS goja

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)

dop251/goja

Your comment was posted 4 minutes ago. That means you still have enough time to edit your comment to change it so it contains real URLs:

<https://github.com/PuerkitoBio/goquery>

<https://github.com/dop251/goja>

(Please do not reply to this comment—I won't be able to delete it once the previous post is fixed if it contains replies.)

Apparently "not depending on Node or V8" means depending on some random Go JS engine instead.

Goja https://github.com/dop251/goja

Either call a JavaScript interpreter like node with exec.Command and read its stdout, or use a pure Go JavaScript interpreter like goja or otto.

Just to also say this is implemented in pure Go we aren't including V8 or any external dependencies we instead use https://github.com/dop251/goja which is a JS VM written completely in Go.

If you want to serialize a function to JSON one idea may be to embed a scripting language like JavaScript into your program. The goja package is a very good solution: a native ES5 JavaScript (with some ES6 syntax support as well) natively implemented in Go so you can get tight data bindings to your Go types and funcs. For your JSON marshalling you could serialize a JavaScript function source (text) and when reloading that, parse that text with goja to be able to run it dynamically in your Go program. Basically you'd need to get away from pure Go for this and towards something that is JSON compatible to (de)serialize to text.

Not really. It was built in-house and I don't know of anything about it that went public. I recall it using Goja for the JS runtime. Code was embedded into the binary (think embed package). There was some kind of sorcery to convert what would be HTTP network calls in the browser into local function calls during SSR, but I'm hazy on how it worked I'm afraid.