4 ms·

Right... this would be a lot more interesting if they picked existing open source implementations and ran them unmodified. It's not like people can drop their u

Right... this would be a lot more interesting if they picked existing open source implementations and ran them unmodified. It's not like people can drop their unmodified software into this and make it scream like what V8 did to plain JavaScript performance.

FabricPaul 15y ago
There's a good reason for that - JavaScript is not a high-performance language. We wouldn't have had to author KL otherwise :) The high-performance parts of the application use a strongly-typed, procedural variant of JS (KL). There's no other way to deal with it. It came up a lot in validation, so we wrote this: http://fabric-engine.com/2011/10/couldnt-you-just-use-javascript-2/ http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... I hope that's helpful
- mmaunder 15y ago
  Is KL open source? In other words, if I modify my JS apps to include KL, am I locked in to you as a vendor? Thanks, interesting post.
  - FabricPaul 15y ago
    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.
    - azakai 15y ago
      > 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?
      - FabricPaul 15y ago
        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.
        azakai 15y ago
        Interesting, thanks. Looking forward to that post.
        FabricPaul 15y ago
        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-javascript-2/ 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
        azakai 15y ago
        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++?)
        FabricPaul 15y ago
        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-windows/ 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.

FabricPaul 15y ago

There's a good reason for that - JavaScript is not a high-performance language. We wouldn't have had to author KL otherwise :) The high-performance parts of the application use a strongly-typed, procedural variant of JS (KL). There's no other way to deal with it. It came up a lot in validation, so we wrote this: http://fabric-engine.com/2011/10/couldnt-you-just-use-javascript-2/ http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... I hope that's helpful

mmaunder 15y ago
Is KL open source? In other words, if I modify my JS apps to include KL, am I locked in to you as a vendor? Thanks, interesting post.
- FabricPaul 15y ago
  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.
  - azakai 15y ago
    > 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?
    - FabricPaul 15y ago
      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.
      - azakai 15y ago
        Interesting, thanks. Looking forward to that post.
        FabricPaul 15y ago
        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-javascript-2/ 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
        azakai 15y ago
        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++?)
        FabricPaul 15y ago
        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-windows/ 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.