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.
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.
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.
I feel like there is a huge missed opportunity that Fusion Lang overlooked.
Rust is not easy to target efficiently, due to the borrow checker, and they likely don't want to dyn Box everything.