Fusion Programming Language(fusion-lang.org) |
Fusion Programming Language(fusion-lang.org) |
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.
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 behavior between targets shows up. Haxe's documentation tends to cover those issues, and lets you know when a behavior is target-dependent, or unspecified. They do try to be consistent between targets whenever possible in a performant way.
Loreline[0] is a recent project which leverages Haxe to build a cross-platform library. Is there a similar project showcasing how Fusion can be used for that?
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.
However, what I like the least in all kind of software is underdocumentation. There's some reference, it's not bad, but actually it's just bunch of examples. If I want to find out exactly how a particular type or statement translates into a specific language, I'll have to dig into the code.
public class HelloFu
{
public static string GetMessage()
{
return "Hello, world!";
}
}
Rust is not easy to target efficiently, due to the borrow checker, and they likely don't want to dyn Box everything.
We could have potentially used Fusion for this had it existed, but I don't know if we would. We didn't have to support 12 different languages, only 2.
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).
This seems for me to be reasonable. Like for a video game with server written in Go/C++/Rust and client written in C#/Javascript, where the same calculations should be done on both sides.
I don't know if fusion is the solution, but I know C isn't.
I feel like there is a huge missed opportunity that Fusion Lang overlooked.
I personally am thinking that developing more programming languages has stopped making sense a long time ago because all of them ignore this untapped market that would help more languages.
C based FFI uniquely privileges C the same way the dollar being a global reserve currency privileges the US, but in the case of currencies the differences in how they work are very small, but with programming languages the differences are substantial.
Half the people working on new programming languages should have been working on GObject competitors instead.
One of the things that is difficult to grasp is that the best FFI is not native to a specific programming language, meaning it does not privilege any specific programming language. Of course this doesn't mean that it cannot be heavily inspired by a particular programming language, it just means that the implementation must be common to all programming languages.
What I mean by the latter is that the features need to be implementable in all programming languages and the easiest way to do it is to define common data types.
The big fallacy that the C FFI advocates present is that it is somehow fine to require full C compiler infrastructure and the C standard library to parse C headers and produce the ABI, but somehow it is the height of evil to define a fat pointer as a C struct consisting of a data pointer and a function pointer and mandating every language to use it, because it is not a C native datatype and only the mythical programming language C is allowed to be used for FFI. I'm pretty sure half the battle could have been won by C having defined common datatypes for the sole purpose of ffi in its standard library.
Your answer just throws in anything that enables programs to communicate somehow, ignoring all the differences and tradeoffs to what is being discussed here. Many of your solutions lock you in to a specific platform, a language or add a non-trivial overhead like message serialization or add an unnecessary complexity to a program. Also, IR does not solve the same problem as ABI.