I was not able to join latest Haxe event, but watched the replay videos afterwards and its cool to see updates from the Haxe team. Thanks a lot for that
During that event, Haxe’s C# target was mentioned as not being a first class citizen, kind of being under-maintained, and that it might eventually be replaced by some DLL assembly export at some point, like what was done for java target being replaced with jvm target.
I’d like to give some feedback regarding the usage I had of C# target, and also some thoughts about its relevance in the future of Haxe and some direct consequences it would have if code exported as plain C# was not a thing anymore.
C# is pretty popular nowadays thanks to Unity being used a lot. Unity is not only used for games, but also more and more as an alternative to Flash for interactive apps in general. Other popular tools like Godot are also embedding C# for scripting (and we can find haxe C# externs for it). That’s the most popular usages I know but there are certainly more to it.
Here’s some concrete feedback about my use of C# target with Unity:
I did use Haxe’s C# target to create a Unity backend for ceramic engine, which made it possible to make a 2D game entirely written in Haxe run inside Unity. Despite the quirks of C# target I had to workaround, I got fairly good performances by using the right Unity APIs (CommandBuffer) and “patching” some C# output (cs/internal/Runtime.cs) to prevent some implicit boxing of primitive values. Even managed to run ceramic editor (written in haxe) run inside Unity.
When using Haxe’s C# target with Unity, I export C# files and let Unity Editor do the compilation itself. I did not prebuild an assembly DLL file from Haxe because it was much more straightforward to let Unity do that : no need to manually link with Unity/.NET assembly files manually. As long as your haxe code has proper externs to Unity API & used plugins, C# files can be exported and then Unity will do the heavy build/link work. Another good addition is that, because C# output is exported as “one file per type/class”, Unity will be faster to reload additional builds as only a few files may have changed since last export.
If C# target was replaced with a DLL-assembly-only export, some issues would arise :
- Unity is very slow to reload a whole assembly DLL file. That would mean every new compilation would freeze unity a lot. Much more than when I’m exporting multiple C# files. Yes, “pre-built” DLL doesn’t mean faster import for Unity.
- Directly generating the assembly DLL would mean (I believe, tell me if I’m wrong) we can’t just use externs referencing other external C# API. We would have to link with other assemblies having that API. That would make the build process much more complicated compared to just dropping C# files into Unity.
So is retiring C# target really an option?
I understand that the original author of C# (and Java) targets is not really around anymore as mentioned by @Simn and it makes it difficult to maintain that target without proper resources, and apparently that target has issues other targets don’t have. I really acknowledge that.
That said, I wanted to share how much exporting C# code from Haxe is still useful, and I believe very relevant in the foreseeable future.
Despite all its current flaws, I hope C# target won’t go away anytime soon, even if it’s not the most efficient generated code, (even if optional args are generating garbage etc…), we can do awesome stuff with it, developers did build things with it and it would be pretty bad news if all that stopped to be possible in some future version of Haxe.
That seemed important for me to share this feedback.
I would also be glad to help in any way I can to keep this target alive or make it better (should I start learning OCaml? Only half-joking, if that could really help eventually, never too late to learn new things)
I am wondering what are the thought of the Haxe team regarding this, as well as the Haxe developers using/wanting to use this target. What do you think about the relevance of Haxe C# target nowadays and in the future (despite the current issues), and what would be the consequences of moving from C# code export to some prebuilt assembly DLL file export?
Anyway, thanks for reading this long and boring feedback and thanks to the Haxe team for making Haxe as good as it is now