[dead]
Fusion Programming Language
41–50 of 53 posts
Re: Fusion Programming Language
#42Now we need an UnFusion programming language that can take code written in any language and convert it into Fusion. With that, you could transform any project from language A into language B.
That language should be called Fusion and this language Fission.
Re: Fusion Programming Language
#43I was a bit surprised to see Ds logo there. Cool.
Re: Fusion Programming Language
#44I'd love to see a comparison to Haxe. https://haxe.org/ I wonder what performance and generated code size/quality look like.
From https://github.com/fusionlanguage/fut/discussions/119#discus... > 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.
But what is the goal of Fusion then in pragmatic words? E.g. Haxe helps to save on development costs when targeting multiple platforms with emphasis on graphical interactive apps (games mostly).
Re: Fusion Programming Language
#45Earlier quoted context omitted.
There have been enormous strides here. We have developed WebAssembly and WIT, with Extism as a chrome over then providing tower of babel between most programming language pairs. We have GraalVM and Truffle to unify languages under one compiler. We have LLVM bitcode to combine languages targeting native machine code for many architectures directly. Swift, Zig, Jai all implement C interop on their own terms. AI agents…
Yes these can be used as alternatives sometimes, but they are not really the same thing. We need a streamlined way for reusable libraries (written in different languages) to be consumed by different languages while not being limited to a specific runtime or platform. When code from different languages needs to be able to run inside the same process, with low calling overhead and avoiding copying when possible. Your a…
im just pointing out (a) a ton of work has gone into this, (b) yielding many options for different use-cases, (c) without dependency on c-abi/c-header.
Re: Fusion Programming Language
#46somewhat funny to the immature mind: "fut" - the name of the compiler binary - is austrian slang for vagina, but in the most obscene, vulgar way possible. a bit like "cunt", but worse.
Re: Fusion Programming Language
#47> 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.
In theory having it in the same language could provide performance benefits, vs reaching out to a C library and dealing with C interop fun. Any language that is JIT'd would have native bytecode to optimise instead of a black box.
Re: Fusion Programming Language
#48[deleted]
Re: Fusion Programming Language
#49Re: Fusion Programming Language
#50It seems similar in concept to Haxe, but focused on writing libraries which are then called from the target language, rather than building your whole application in Fusion. Is that correct? How are exceptions translated to languages which don't have exceptions, like C? The amount of targets seems impressive, but I don't see anything resembling a standard library. Usually, it's in the standard library where diverging…