> I've read about Haxe in 2000s, before I started my work on Fusion. They have different design goals: in Haxe you create whole apps, in Fusion you create components to be used from other languages. Haxe has syntax similar to the (now dead) ActionScript, Fusion is similar to C#. Fusion transpiles to C, D, Swift, TypeScript, OpenCL and Haxe does not.
At a time I was very interested in haxe, but their focus on games made it (perceived as) lacking in the area I wanted to use it (cross platform client-server apps). Recently rust seems to have taken this role for me.
Nice idea. I'm just wondering how to debug code written in fusion... probably you must focus on one of outputs, debug that one, and then back-fit the changes to the fusion source. :/
> implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase
Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.
ORMs and variations like Protobuf or things that have to be cross-plateform in the wide sense. The perspective that the same source will behave the same in various environments, and "velocity" trumps performance considerations. If you want to work on things where performance matters, consider embedded/firmware programming ;-)
I think the target application is writing the same algorithm in multiple places with a guarantee that the logic will be based on a single source of truth. Not unlike Protocol Buffers work to standardize data layout across platforms.
It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any language that can work with that (i.e. any language).
The point, AFAICT, is not in using all capabilities of all the target languages. Rather, it's about expressing some narrower class of computations and grafting them seamlessly into the target languages. Think of data formats, parsers, network protocols, stuff like handling and rendering of text, etc.
Fusion is a programming language designed for implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase.
I suppose you can write various algorithms in it, and have that code natively trsnspiled to different languages, for ease of native interoperability. It's unlikely to produce the absolutely most optimized code, but the lack of the interface translation barrier (aka FFI) may more than compensate for it.
Rust is not easy to target efficiently, due to the borrow checker, and they likely don't want to dyn Box everything.
I wonder what performance and generated code size/quality look like.
> I've read about Haxe in 2000s, before I started my work on Fusion. They have different design goals: in Haxe you create whole apps, in Fusion you create components to be used from other languages. Haxe has syntax similar to the (now dead) ActionScript, Fusion is similar to C#. Fusion transpiles to C, D, Swift, TypeScript, OpenCL and Haxe does not.
Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.
It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any language that can work with that (i.e. any language).
I don't know if fusion is the solution, but I know C isn't.
Rust is not easy to target efficiently, due to the borrow checker, and they likely don't want to dyn Box everything.