31–40 of 46 posts
I understand the need for AGPL so this can be monetized, but I really wish there was a price on the commercial licensing page instead of just requiring me to contact y'all. Why do I have to "request licensing information", why can't it be made publicly visible?
Earlier quoted context omitted.
lol :) Read this older HN thread - 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/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, s…
I'm mainly referring to the article here, which is rather ambiguous and mis-stated in its wording, as well as the submission title, which is entirely missing the point of what Fabric does. I don't doubt that you have more in-depth information on your site, or that, for that matter, using Fabric from your scripting-language of choice can actually speed up your code (considering things like Cython have existed for a wh…
Earlier quoted context omitted.
I'm mainly referring to the article here, which is rather ambiguous and mis-stated in its wording, as well as the submission title, which is entirely missing the point of what Fabric does. I don't doubt that you have more in-depth information on your site, or that, for that matter, using Fabric from your scripting-language of choice can actually speed up your code (considering things like Cython have existed for a wh…
p.s. I'm glad to hear about the addition of the flux capacitor
Earlier quoted context omitted.
not really - Fabric is integrated with dynamic languages, we 're not interpreting JS or Python (we work with both languages). Fabric is basically a high-performance threading engine that you can call from your dynamic language - the key element is that the operator code (KL) enables the high-performance. This KL is only required for the operators, and is not as difficult or complex as C/C++ to use - it's designed pur…
> Fabric is integrated with dynamic languages, we 're not interpreting JS or Python (we work with both languages). Neither does Cython. > Fabric is basically a high-performance threading engine that you can call from your dynamic language Well Cython is for writing Python modules, so it's integrated with Python only. But that's pretty much it. > the key element is that the operator code (KL) enables the high-performa…
This isn't JavaScript being as fast as C++, it's writing critical sections in a low-level language being as good as writing the whole app in a low-level language.
agreed - I was pulled up on this here last year when we published our benchmarks :) The other thing to remember is the low-level language we use sets a lower bar to entry than say C - the benefit of designing for a specific set of goals (ease of use, performance and security). That said, if you're familiar with C or JavaScript, then KL will be very familiar.
Earlier quoted context omitted.
agreed - I was pulled up on this here last year when we published our benchmarks :) The other thing to remember is the low-level language we use sets a lower bar to entry than say C - the benefit of designing for a specific set of goals (ease of use, performance and security). That said, if you're familiar with C or JavaScript, then KL will be very familiar.
You should do an introductory article for technical audiences yourself perhaps. Or maybe you already have one?
Earlier quoted context omitted.
What's wrong with pointers? I quite enjoy working with pointers - they are a very simple concept.
Using pointers adds a certain amount of complexity, and they also introduce the possibility of security problems. This was particularly important for the work we were doing on the browser plug-in. For the type of work that developers use KL for, they aren't needed.
NACL, which is only somewhat similar in that it runs native code via the browser, went to great lengths to demonstrate how their sandboxing worked to address the FUD of running native code in the browser. I have a very similar FUD about executing Fabric LLVM code from arbitrary websites.
To clarify where I'm coming from, I am a javascript / ruby dev and although I have worked in C I do not claim to understand the inner workings of LLVM or have ever worked with it. If there is an implicit reason why building on LLVM would sandbox code written in fabric it is not implicit to me. I doubt I am alone in this and would greatly appreciate an explanation of Fabric's sandboxing.
Earlier quoted context omitted.
not really - Fabric is integrated with dynamic languages, we 're not interpreting JS or Python (we work with both languages). Fabric is basically a high-performance threading engine that you can call from your dynamic language - the key element is that the operator code (KL) enables the high-performance. This KL is only required for the operators, and is not as difficult or complex as C/C++ to use - it's designed pur…
Replying to comment below (can't see a reply button) - please correct me if I'm wrong, but I don't see anything about Cython handling multi-threading and I don't see anything about dynamic compilation on target. I just had a flick through their documentation, so if this stuff is in there then I missed it...
There are also some parallel features:
Interesting, but why the KL DSL? It seems you could have either used something like OpenCL, or, went with a language like Go, Dart, of haxe.
The rationale for creating KL was that we had some specific goals, and we couldn't find an existing language that did everything we wanted - the requirement of being high-performance _and_ easy to use was critical. We also had security concerns (we started out as a browser plug-in), so it also had to be pointerless. Given that we have a fairly narrow scope (writing high-performance operator code), we decided the best path was a DSL. If we didn't have the security concern, we would have stuck with C++ - but that wouldn't have had the lower bar to entry that KL has.
My co-founder who wrote KL still thinks we were crazy to do it - 'the world does not need another language' :)