Ask HN: Fast, simple, unbreakably-sandboxed embeddable scripting language? | Hacker News Reader

Ask HN: Fast, simple, unbreakably-sandboxed embeddable scripting language?

2 pointsi336_1 comment

For a while now, I've been pondering problem areas that would ideally be solved by domain-specialized variants of "client-server architecture with client-side arbitrary code execution." Perhaps understandably, I've historically shied away from exploring these problem areas practically due to the fact that I'm well aware that it's incredibly hard to find an effective ideal balance between client-side performance and safe code execution.

I don't think I need the kind of performance that can only be obtained via JIT execution; I'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't think I need to worry about JIT, thankfully.

That said, I am 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't know if its token parsing overhead would make it slower than a binary-bytecode-based alternative (?).

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 "what about a 25MHz CPU with 4MB of RAM" is borderline a waste of time, but performance, albeit sans JIT, is definitely something I'm also interested in knowing about.

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

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

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

Reply on news.ycombinator.com