
Ask HN: Fast, simple, unbreakably-sandboxed embeddable scripting language? - i336_
For a while now, I&#x27;ve been pondering problem areas that would ideally be solved by domain-specialized variants of &quot;client-server architecture with client-side arbitrary code execution.&quot; Perhaps understandably, I&#x27;ve historically shied away from exploring these problem areas practically due to the fact that I&#x27;m well aware that it&#x27;s incredibly hard to find an effective ideal balance between client-side performance and safe code execution.<p>I don&#x27;t think I need the kind of performance that can only be obtained via JIT execution; I&#x27;m looking rather to run code that will update 2D graphics (alongside performing small amounts of 2D-related math), handling user interaction, etc, so I don&#x27;t think I need to worry about JIT, thankfully.<p>That said, I <i>am</i> especially interested in systems that are proven and have existed for a while, so that I can extend into areas of industrial control and the like, which generally like platforms built on stuff that has existed in the public consciousness for very long amounts of time. Forth comes to mind, but I don&#x27;t know if its token parsing overhead would make it slower than a binary-bytecode-based alternative (?).<p>The lowest common denominator of what kinds of processing power one should expect to run in has increased quite exponentially in recent years, so trying to solve for potential scenarios like &quot;what about a 25MHz CPU with 4MB of RAM&quot; is borderline a waste of time, but performance, albeit sans JIT, is definitely something I&#x27;m also interested in knowing about.
======
i336_
_A sidenote on JIT:_ I wrote the following while working out the structure of
my post; I figured it wouldn't hurt too much to post it too. The bulk of my
question is above; what follows is more or less incidental.

I understand that JIT has something of a role in performance, and that modern
Javascript engines couple the performance gains of JIT execution with a mind-
boggling slew of different security and sandboxing techniques that aim to
prevent unwanted data colliding with the CPU's instruction pointer while still
allowing near-C levels of performance. Thing is, what generally makes
browsers' sometimes unbelievable JIT-powered performance[1] possible is the
fact that the major JS engines - V8, JavaScriptCore, Chakra, Spidermonkey -
have huge companies behind them that have the resources to fund continuous R&D
to iterate on performance while keeping abreast of security issues.

[1]: [http://www.gopherjs.org/blog/2015/09/28/surprises-in-
gopherj...](http://www.gopherjs.org/blog/2015/09/28/surprises-in-gopherjs-
performance/)

But I'm not a browser manufacturer, or a computer science major (or even
undergrad). I'm just a tinkerer who wants to play around with ideas that
generally need safe remote code execution in a way that is transparent (to the
extent a high-level competent end user could introspect all operations and
control low-level settings) and trustable (for both the end user, who wants
control of their device, and the developer, who wants a predictable
environment).

I understand that JIT is generally incredibly hard to get right - this LuaJIT
punchthrough[2] is an enlightening read (if just to learn what involved Lua
code can look like :P) - and that once you flip the execute bit on any of the
memory the OS has allocated it's basically game on to start juggling how much
to hypervise so performance doesn't get hit too much.

[2]: [http://www.corsix.org/content/malicious-luajit-
bytecode](http://www.corsix.org/content/malicious-luajit-bytecode)

The Web also has a mind-boggling churn rate, which can be offputting in some
contexts/situations that favor stability and consistency.

