5 ms·

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

by Amadiro 15y ago

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 15y ago
lol :) Read this older HN thread - http://news.ycombinator.com/item?id=3227905 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/Server 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, 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/ 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 ;)
- FabricPaul 15y ago
  p.s. Fabric Engine 2.0 has a flux capacitor
- Amadiro 15y ago
  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 15y ago
    p.s. I'm glad to hear about the addition of the flux capacitor
    - FabricPaul 15y ago
      it's awesome. Investors are going crazy
  - FabricPaul 15y ago
    got it - thanks for the clarification :)

by Amadiro 15y ago

FabricPaul 15y ago

lol :) Read this older HN thread - http://news.ycombinator.com/item?id=3227905 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/Server 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, 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/ 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 ;)

FabricPaul 15y ago
p.s. Fabric Engine 2.0 has a flux capacitor
Amadiro 15y ago
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 15y ago
  p.s. I'm glad to hear about the addition of the flux capacitor
  - FabricPaul 15y ago
    it's awesome. Investors are going crazy
- FabricPaul 15y ago
  got it - thanks for the clarification :)