I wonder what performance and generated code size/quality look like.
nine_k 22 minutes ago [-]
Apparently Haxe cannot target OpenCL. It can target PHP and Lua instead.
Panzerschrek 13 minutes ago [-]
> 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.
4k0hz 38 seconds ago [-]
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).
knhung 50 minutes ago [-]
The idea it's good but hard to make it good. A universal language is hard to optimise for a particular language.
nine_k 9 minutes ago [-]
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.
jdw64 2 hours ago [-]
Wow, this is really fusion. I like it.
efrecon 3 days ago [-]
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.
What are the use cases? I am curious why Rust was not targeted.
nine_k 16 minutes ago [-]
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.
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).
Rust is not easy to target efficiently, due to the borrow checker, and they likely don't want to dyn Box everything.