wallet/docs/libraries/scripting.md

---
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.