
Fabric Engine: JavaScript as fast as C++ - jk4930
http://www.h-online.com/open/news/item/Fabric-Engine-brings-JavaScript-to-C-level-1497983.html
======
Amadiro
Reality check:

[x] Claims to support a multitude of languages with wildly varying semantics
while still achieving some goal that seems unrealistic (or thus-far un-
achieved) even for a single one

[x] Claims to achieve performance similar to C/C++/fortran/some other
traditionally-considered-fast language

[x] Claims that some traditionally-considered-hard-to-do-task will now become
easy

[x] Uses buzzwords like "in the cloud"

[x] Shows meaningless benchmarks without context, code or an in-depth look at
the actual bottlenecks of the benchmarked code, suggesting the particular
solution by far exceeds all the competitors

[ ] Extensive usage of the words "flux capacitor" or "Gigawatts"

~~~
FabricPaul
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...](https://github.com/fabric-
engine/Benchmarks/tree/master/Server))

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/>

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 ;)

~~~
Amadiro
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 while.)

~~~
Amadiro
p.s. I'm glad to hear about the addition of the flux capacitor

~~~
FabricPaul
it's awesome. Investors are going crazy

------
anonymoushn
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.

~~~
FabricPaul
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.

~~~
codedivine
You should do an introductory article for technical audiences yourself
perhaps. Or maybe you already have one?

~~~
FabricPaul
we did a lot of documentation work for launch - the overview is a good place
to start: [http://documentation.fabric-
engine.com/latest/FabricEngine-O...](http://documentation.fabric-
engine.com/latest/FabricEngine-Overview.html)

------
pdehaan

       Fabric Engine has released version 1.0 of its platform for multi-threaded optimised execution of scripting languages.
    

Kind of cool, if somewhat misleading. The way that's written seems to imply it
speeds up the scripting language itself, but reading further it seems to just
be a lower level language that's easy to use from within those scripting
languages. Using an FFI to speed things up is nothing new, but making it
easier is always nice.

~~~
FabricPaul
The 'new' part relates to using LLVM to do the compilation on target - this
actually makes a big difference in workflow, and is also much more familiar to
people used to developing with dynamic languages. It also opens up some cool
possibilities around scaling of computation...

------
kodablah
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?

~~~
FabricPaul
You're right - it should be publicly visible. We're working on it - it will be
updated and public in the next week. We'll be offering subscription pricing -
so initially it will be a monthly that allows you to run x number of
instances.

------
tlack
Anyone out there done a deep dive into this one? What's the catch?

~~~
binarycrusader
This seems like a non-starter to me:

    
    
      The Fabric Engine core and language bindings are made
      available as open source under the AGPL v3 license, with
      commercial licensing options available on request and
      paid-for support options for developers. Version 1.0 is
      available to download from the company's site.
    

Personally, I'd say "screw it", and use V8.

~~~
anonymoushn
AGPL is a bit bothersome. I'd rather be able to release my code under a non-
viral license.

~~~
FabricPaul
we offer commercial licensing that allows devs to bypass the AGPL
requirements. I'll update the site info soon to show the subscription pricing
options.

------
cromwellian
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.

~~~
FabricPaul
OpenCL/CUDA are GPGPU programming languages - that's something we're getting
to soon :) We previously exposed OpenCL as an extension, but took it out
because it's a nightmare to support. We're looking at it again at the moment -
it's pretty challenging to write GPU code, so it's hard to see how much
benefit developers will get from it until we can target nicely from KL. One
for the longer term :)

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' :)

~~~
FabricPaul
we wrote this piece last year - it's focused more on why JS isn't enough, but
there's some useful info about KL in there.
[http://fabricengine.com/2011/10/couldnt-you-just-use-
javascr...](http://fabricengine.com/2011/10/couldnt-you-just-use-
javascript-2/)

