lol :) Read this older HN thread - http://news.ycombinator.com/item?id=3227905 http://news.ycombinator.com/item?id=3227905 - a few people took our code and trie

lol :) Read this older HN thread - http://news.ycombinator.com/item?id=3227905 http://news.ycombinator.com/item?id=3227905 - a few people took our code and tried to make it faster in C/C++ and Java. We made our benchmark code available: (https://github.com/fabric-engine/Benchmarks/tree/master/Server https://github.com/fabric-engine/Benchmarks/tree/master/Serv...) If you have a standalone module for the high-performance, then of course you can bind it to different languages. We're not interpreting the dynamic language, so therefore semantic differences between languages aren't a major factor. If you think about what we're doing, it isn't surprising that we'd hit that kind of performance - after all, we're asking the developer for a concurrency-friendly description, then taking their operator code (which is strongly typed) and compiling it on target. It's more about the dynamic compilation that LLVM enables, and the ease of access for regular developers. It runs on instances - how do you describe that other than to say 'in the cloud'? The benchmarks are properly presented and explained: http://fabricengine.com/technology/benchmarks/ http://fabricengine.com/technology/benchmarks/ I understand the skepticism, but we have been open with our data and the code we used for our benchmarks. We're not claiming to go faster than light here ;)