Haxe 4.3(haxe.org) |
Haxe 4.3(haxe.org) |
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.
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.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This is stuff that is incredibly hard to justify as a hobby project but definitely in the realm of what Haxe does well.
I guess to describe haxe to someone, i'd say it's closer to typescript, but compiles down to many different languages.
And seems like with hashlink I can compile to a single binary instead of the nightmare of electron or Python gui apps packaging
I've tried tauri + neutralino this year (both electron alternatives), and they depend immensely on buildsystems + platform targeting. flutter + react native play in this space too
Even if Haxe was effectively feature complete, I would expect maintenance for bug fixes and keeping up to date with evolving platforms and backends, especially because Haxe supports so many targets.
The nightly builds should probably be promoted to patch releases more often though.
More importantly the language and IDE support are a lot better than GDScript.
And as others mentioned, Haxe is cross-platform. But not "cross-platform" like some languages claim to be: it's been cross-platform ever since the early days and is very battle-tested
For example, wanna deploy a validation library that checks something and have it available in a ton of language directly? Using Haxe, you can get this very cheap.
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 :)
A lot of what I encountered from my time using it(which I might return to someday) was that it became more irritating as you introduced more platform dependencies, but mostly because it became harder to build the project. And this was disproportionately true for targets with complex build processes(SWF was one of them back in the day, and C++ still is).
Some of it does get mitigated by doing a double layer of abstraction: your platform code has a shell of functionality that is handled using the native paradigms, but exposes an interface that Haxe code calls. And the Haxe code accesses your own abstractions, not the native ones.
But doing all of that can get away from "just getting a result", because then you're pushing more of the development onto the native target. If you don't have a clear view of what abstraction you want, you can get stuck on designing it.
The key idea is portable to any prog.lang. you might like, although many will not be as run-time efficient as Nim, C, etc. and many may not be as safe as Nim.