[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"
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'?
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 ;)
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.)
[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"