Just some rambling thoughts per our conversation

Web-Based Architectures

• complex interactions between multiple pieces of software
• often an expert is required to "harden" a system with so many moving parts

VMs

• necessary for write once run everywhere
• multiple vms can compete for resources in ways that hide resource needs of individual processes (threads) contained within them

VM as OS

• Runs only on one combination of hardware as exposed by VirtualBox (or some other VM)
• Custom linux installation, missing significant software as compared to a standard linux system.
• login() which usually owns all other processes after boot, will be replaced with a ‘system()’ program which forks into an ‘aREPL’, asynchronous REPL, and an nginx (or some other webserver) implementation
• The system presents configuration options via the standard monitor output channels, these can be serialized to disk in between runs, eventually this can be exposed as a secure ncurses interface
• the ‘expert level’ configuration is provided by the language developers, potential flaw: each 0-day explit effects all systems
• the webserver reads a request an http put request to http://foo.bar/eval that looks like:
  {
  souce: Byte array representing source input string
  }

and returns a JSONs that looks like:
{
out: standard output channel
err: standard input channel
}
whenever the output buffer size is reached

The byte array source is passed to the aREPL where it’s read, evaluated and when nevessary things are printed back

Tying systems together

L should implement many web-spec. functions as basic language constructs implemented in C and linked against the standard libraries that provide those functions, things like:

scp, sendEmal, get, put, post, update, delete (by no means exhaustive)

as well as all the language features given in the spec

provide a modular way of loading new “sys-tasks” into the language