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.
Does anyone have a good non-gaming use case for Haxe? It feels very nice to have multiple compilation targets and the language is great, but I never found an excuse to use it.
The creator of http://haxeui.org/ makes a lot of (closed) projects for the health sector.
I personally like to use to make some wxwidgets utilities apps with it. (And being able the html5 js target and android/ios (with openfl) target.
Internal frameworks seem to be a popular scenario for Haxe. Something where you are the vendor for the platform abstraction, not the consumer. Or you have a codebase that needs some incremental migration between targets.
This is stuff that is incredibly hard to justify as a hobby project but definitely in the realm of what Haxe does well.
same here, it's a forever top of mind but never to be practically used. The thought of having one language but can dish out frontend in JS, backend in python, jobs in C has been a dream of mine.
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
super interesting that a big part of the lift here is buildsystems + targeting different platforms
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
Haxe development doesn’t seem very active: the last minor release, 4.2.5, was 13 months ago. The last major release, 4.2.0, was two years ago.
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.
I’m glad to hear that. I had wondered whether most Haxe users used the nightly releases. That might be more common for projects that have a few main contributors: they fix issues blocking them and use their own builds without the overhead making new public releases.
Haxe + https://heaps.io/ (game engine) + https://ldtk.io/ (level editor) presumably gets you most of the features Godot has (though I don't know because I don't really do game-dev)
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
Being able to cross-transpile (cross-compilation basically) to other languages is a huge selling point. You can, in one language, output libraries that are compatible with: JavaScript, Flash, Neko, PHP, C++, Cppia, Java, JVM, C#, Python, Lua, HashLink
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.
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 :)
Haxe appeals to a lot of Flash game developers that would prefer to rely more heavily on code than a full blown game engine. A lot of people really like the “display list” (scene graph) API of Flash and a bunch of Haxe libraries follow similar patterns.
Readit News
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...
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.
https://haxe.org/download/list/
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 :)
[1] https://aurel300.github.io/ammer/
Dead Comment