[ashleymoran]

I think this is a case of premature optimisation. Trolls under Bridges is struggling to hit v1.0 due to the limited memory capacity of trolls, but someone is hard at work on a Node.js implementation of the interpreter. This will allow spawning a new worker process, or "troglodyte", for each request, and will be totally webscale (there will be no unnecessary trolling for events).

In addition, there's also a JVM port of TrollScript in the works, which will add a static type system to the language for troll-safety. This should alleviate any concerns that the language would be unmaintainable for large systems. JTrollScript will also have type inference to maintain the terseness of the original language.

[_3ex7]

Re: Node.js implementation

my buddy has been hacking on this and he says the benefit of being able to troll on the server the same way you troll the client is a huge benefit.

[reinhardt]

True, but at the same time it's no match to the TIT (Troll In Time) compiler in cases where every ounce of performance counts.