--- title: Scripting ... Initially we intend to implement human to human secret messaging, with money that can be transferred in the message, and the capability to make messages public and provably linked with an identity But obviously we are eventually going to need bot responses, and bot scripts that can interact with the recipient within a sandbox. Not wanting to repeat the mistakes of the internet, we will want the same bot language generating responses, and interacting with the recipient. There is a [list](https://github.com/dbohdan/embedded-scripting-languages){target="_blank"} of embeddable scripting languages. # Javascript Which has a vast ecology, an army of midwit programmers, and vast collection of tools and libraries. Vscode is written in typescript, which compiles to javascript, and runs under Electron. We already have a similar embedding tool in wxWidgets, wxWebview, which allows javascript to call C++ through custom schemes and virtual file systems, and C++ to call javascript through `RunScriptAsync()` and `RunScript()`. Large projects tend to be written in a framework that supports typescript * Create React App * Next.js * Gatsby What can be done in Electron can be done in wxWebview, though not necessarily as easily. WxWebview is a somewhat messier and trickier to use Electron, with considerably inferior performance in script execution time, but with vastly better integration with C++ # Lua and Python Lua and python are readily embeddable, but [the language shootout](https://benchmarksgame-team.pages.debian.net/benchmarksgame/) tells us they are terribly slow. [Embedding LuaJIT in 30 minutes]:https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-minutes-or-so/ {target="_blank"} Lua, however, has `LuaJIT`, which is about ten times faster than `Lua`, which makes it only about four or five times slower than JavaScript under `node.js`. It is highly portable, though I get the feeling that porting it to windows is going to be a pain, but then it is never going to be expected to call the windows file and gui operations. Other people say it is faster than JavaScript, but avoid comparison to Nodejs. But it is allegedly faster than any JavaScript I am likely to be able to embed. [Embedding LuaJIT in 30 minutes] gives as its example code a DNS server written in embedded LUA. Note that it is very easy to embed LUAJIT in such a way that the operations run amazingly slow. Web application firewall that is used by Cloudfare was rewritten from 37000 lines of C to 2000 lines of lua. And it handles requests in 2ms. But it needed profiling and all that to find the slowdown gotchas - everyone who uses LUA JIT winds up spending some time and effort to avoid horrible pointless slow operations and they need to know what they are doing. He recommends embedded LUA JIT as easier to embed and interface to C than straight LUA. Well, it would be easier for someone who has an good understanding of what is happening under the hood. He also addresses sandboxing. Seems that LUA JIT sandboxes just fine (unlike Javascript). Checking his links, it seems that embedded LUA JIT is widely used in many important applications that need to be fast and have a great deal of money behind them. LUA JIT is not available on the computer benchmarks shootout. The JIT people say the shootout maintainer is being hostile and difficult, the shootout maintainer is kind of apt to change the subject and imply the JIT people are not getting off their asses, but I can see they have done a decent amount of work to get their stuff included. LUA JIT is a significantly different dialect to LUA, and tends to get rather different idioms as a result of profiling driven optimization. It looks like common LUA idioms are apt to bite in LUA JIT for reasons that are not easy to intuit. Thus there is in effect some hand precompiling for LUA JIT. Anecdotal data on speed for LUA JIT: * lua-JIT is faster than Java-with-JIT (the sun Java), lua-JIT is faster than V8 (Javascript-with-JIT), etc, ... * As Justin Cormack notes in the comments to the answer below, it is crucial to remark that JITed calls to native C functions (rather than lua_CFunctions) are extremely fast (zero overhead) when using the LuaJIT ffi. That's a double win: you don't have to write bindings anymore, and you get on-the-metal performance. Using LJ to call into a C library can yield spooky-fast performance even when doing heavy work on the Lua side. * I am personally surprised at luajit's performance. We use it in the network space, and its performance is outstanding. I had used it in the past is a different manner, and its performance was 'ok'. Implementation architecture really is important with this framework. You can get C perf, with minimal effort. There are limitations, but we have worked around all of them now. Highly recommended. # Lisp Lisp is sort of embeddable, startlingly fast, and is enormously capable, but it is huge, and not all that portable. # Angelscript Very few of the scripting languages make promises about sandbox capability, and I know there is enormous grief over sandboxing JavaScript. It can be done, but it is a big project. Angelscript *does* make promises about sandbox capability, but I have absolutely no information its capability and performance. # Tcl Tcl is event loop oriented. But hell, I have an event loop. I want my events to put data in memory, then launch a script for the event, the script does something with the data, generates some new data, fires some events that will make use of the data, and finishes. # Memory management Given that I want programs to be short and quickly terminate, maybe we do not need dynamic memory management and garbage collection. Lua is slowed by dynamic memory management. But with event orientation, dynamic memory management is complete waste, since your only memory management is allocating continuation objects to be fired on the next event - which is to say, all memory management is explicit, when an event handler detaches.