Haxe 4.3

I’m very curious about Haxe. From using ldtk and looking into haxeui and openfl, it looks like it could be good for multi platform gui apps. I’ve used godot for that purpose before but all the game stuff and limited libraries gets in the way of making it easy for gui development.

And seems like with hashlink I can compile to a single binary instead of the nightmare of electron or Python gui apps packaging

I really love Haxe. A truly multi-paradigm language with good support for GADTs, OOP, structural and nominal types, lambdas, and a lot of practical sugar on top. The macro system and abstract types add enormous flexibility that I miss when going back to C# or Java.

The language is a bit verbose, but I prefer it and generally add type annotations instead of using type inference (unless I’m dealing with a super gnarly generic type).

The language shines in the graphics space since some of the Flash community gravitated to Haxe. I’ve found that it works great as a client/server language similar to a typescript frontend/backend stack. The benefit with Haxe is that the backend isn’t limited to Node, it can run on JVM, bare metal with C++, Openresty with Lua, and anywhere Python runs. It’s pretty easy to implement F# style type providers with the macro system as well.

There is also a C# target, however, there are talks of deprecating. Hopefully we will see a revival with Reflaxe, another way to make new targets, or maybe even a CLR target. https://github.com/RobertBorghese/reflaxe

Lastly, I’m very excited about Ammer the universal FFI for Haxe by Aurel. https://aurel300.github.io/ammer/ My hope is that the community will rally around Ammer and bring in a lot of native libraries to all targets.

Last time I checked on master - 2-3 months ago - ?. was implemented, but ?? was still missing. Good to see the implementation finalized. I also saw `overload` for inlines, that's really nice, having to expose functions taking Any and dispatching on dynamic type was one of the pain points in Haxe for me. A shame it's only for inline functions for now. Local static vars is something I didn't see, it looks like static variables in functions in C, right? I'm not quite sure how useful that would be. I guess the scopes are not shared, so `static var instance` in one method is different than `instance` declared the same way in another function. Still, the properties with getters also work. Better errors are always welcome, custom defines... I know I wanted these at some point, but can't recall right now what for. Stdlib got a bit more of concurrency support with Condition and Semaphore - good, my target doesn't do threading, but has coroutines, so having more options to control concurrency is nice.

All in all, very nice release with null-related operators being the feature I missed the most. I'm not sure about default type parameters, and numerical suffixes don't matter on my platform (everything is a double on runtime), but numerical separators are nice. Steadily, Haxe gets easier to use and safer. Macros are becoming more ergonomic, too, which is great, as they're essential to effective Haxe programming.

In practice, this is hard. The problem is that you need to either have all the functionality you use written in Haxe - which is rarely if ever possible - or you have externs to equivalent libraries on all platforms. The libraries produced will also need to be interfaced from outside somehow, and for some of the targets you'll have to write additional wrappers for your lib. It's really hard to pull off when targeting more than 2-3 targets.

Another commenter linked to Ammer[1], a universal FFI framework (apparently, it's my first time seeing it) - it might be just the thing needed to make multiplatform Haxe libraries way easier to write and distribute. I'd welcome that :)

[1] https://aurel300.github.io/ammer/

Also, here is an official repo where you can look at proposed and accepted changes: https://github.com/HaxeFoundation/haxe-evolution