Hacker News Reader

Comment by FabricPaul | Hacker News Reader

Hi there - the engine itself is closed source, everything we build on top of it is open-sourced. So if someone built a competing engine that used KL (not sure why they would!), then you would be free to take your code wherever you liked.

If we move to type inference in the future, then the KL code will be JavaScript. Right now we declare types, but in the future we'd like to just throw a compiler error if we can't infer. That way people will have completely portable code.

View on HN

> That way people will have completely portable code.

Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?

It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable working with - so we looked at JS and decided we could create a variant for performance.

We don't give pointers, and we do things client-side like guarded arrays (not necessary on the server). Memory management is handled by the core. I will get our guys to put a post up that covers KL in more detail - security was a major consideration for us.

Interesting, thanks. Looking forward to that post.

I linked this elsewhere on the thread, but you might find it interesting in the meantime: http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc...

There are more details on KL, and the reasoning why we didn't use JavaScript

Thanks, that was interesting.

While I have you here :) , can you please elaborate on your Bullet/Fabric demo? Specifically, how did you get the Bullet C++ code to run on the Fabric Engine? (Since that doesn't use C++?)

Sure - we designed Fabric to be extendable, so it can include existing c++ libraries. So we just integrated the Bullet SDK. http://fabric-engine.com/2011/11/building-extensions-on-wind... covers the extension model in detail.

Does that answer your question properly? I can get more info if needed.

Thanks, that does answer my question.

I asked because I work on compiling C++ into JavaScript, and I was curious if your technology included something to compile C++ into KL.

I assume integrating existing C++ libraries to Fabric Engine has no security model, then?

Right - they have to be 'trusted', much like a plugin. People will have to explicitly choose to install them. Right now we bundle them all in he plugin, but that's just until we write the manager

Makes sense, thanks again for all the replies.

Reply on news.ycombinator.com