Does anyone have any real world experiences with Haxe? I've been hearing about it for years and generally thought "wow, that's neat!" but that's been it. Does it actually achieve what it aims for?
I have used Haxe off and on nearly from the beginning. I still use it and was doing some coding earlier today in it.
Two points of friction around it that tend to show up are in tooling and debugging. Haxe is what I like to call "parasitic" in that it leverages existing stacks really easily, but then the tooling of those stacks doesn't always offer the affordances you want.
For example, when Flash was still a major target, Haxe did have some SWF generation functionality, but it didn't accommodate every type of asset equally well and there was a bit of a puzzle - not an insurmountable one, but bigger and more opaque than anyone would face from Adobe's tools - in getting the binding of the embedded asset accessible from your Haxe code. The puzzle persisted through a lot of the SWF features(things like networking sandboxes, which would be used if you wanted to e.g. embed ads in a game, were related to how the SWF was built and delivered) and could result in a lot of timewasting.
Likewise, while the language is extremely savvy about offering access to the low-level functions of different targets - eventually you do come to debugging the generated code. Not because the compiler has failed(it's very reliable) but because there is some kind of platform-specific issue to be solved. And again, it's going to be more opaque to debug that than "doing it native".
The upside of this is that you can choose your target for everyday debugging, and therefore minimize the suck. It can actually be very productive and painless. (Edit: and the language is really up to speed with the idioms in current PLs, so it's often the better choice for writing abstractions.)
A healthy way to apply Haxe is to identify the places where you can put the platform code behind an interface, code that natively, and then code to the interface in Haxe for the rest. That way, you get the fluidity of being able to switch targets and you aren't jumping between layers so often. But this does come with the cost of having to build up a useful interface and really "own your own stack". It's not just-works technology, although it can come close with some of the frameworks.
I implemented the BlockStudio visual programming language (authoring environment + runtime) in haxe [0].
I'm also migrating the website (currently Python) over to it -- I can share data type declarations between server and client-side code, which give me compile-time guarantees that my api calls and return values are not malformed.
A previous employer used it when they wanted to move away from ActionScript due to flash EOL approaching as the goal of transpiling to multiple platforms was appealing, performance was not the best however and they ended up moving towards a different approach. Still, by the time I joined a few primitive libs were maintained in Haxe because they were stable and there was no reason to migrate them, so I had to dabble with Haxe a few times at work, not saying it was terrible, but it was far less enjoyable then our much more robust TS setup, this is arguable tho as since it had been deprecated by the company it received fewer tooling support in house.
Yeah i have used it to make some, small but not trivial games. I really enjoy it. I mostly just target the HashLink vm as its met all of my needs.
The actual language is great. I am a long time ago former flash developer, and heaps.io and haxe has captured a lot of the enjoyment I used to have making games for newgrounds
I used it once years ago. A client wanted rotating ads in banners in Flash for a web site. I wanted to be able to reuse the code for JS. We negotiated the copyright staying with me for a discount on the feature. I did it in Haxe (then stylized as something like hAxE or HaXe or so) and compiled it to both targets. It's not a complex thing like Dead Cells, but it was a quick and easy language to pick up and use from zero prior experience with it.
I've not touched it in years, but if I ever do a side project it'll be one of the tools I'm likely to use.
Two points of friction around it that tend to show up are in tooling and debugging. Haxe is what I like to call "parasitic" in that it leverages existing stacks really easily, but then the tooling of those stacks doesn't always offer the affordances you want.
For example, when Flash was still a major target, Haxe did have some SWF generation functionality, but it didn't accommodate every type of asset equally well and there was a bit of a puzzle - not an insurmountable one, but bigger and more opaque than anyone would face from Adobe's tools - in getting the binding of the embedded asset accessible from your Haxe code. The puzzle persisted through a lot of the SWF features(things like networking sandboxes, which would be used if you wanted to e.g. embed ads in a game, were related to how the SWF was built and delivered) and could result in a lot of timewasting.
Likewise, while the language is extremely savvy about offering access to the low-level functions of different targets - eventually you do come to debugging the generated code. Not because the compiler has failed(it's very reliable) but because there is some kind of platform-specific issue to be solved. And again, it's going to be more opaque to debug that than "doing it native".
The upside of this is that you can choose your target for everyday debugging, and therefore minimize the suck. It can actually be very productive and painless. (Edit: and the language is really up to speed with the idioms in current PLs, so it's often the better choice for writing abstractions.)
A healthy way to apply Haxe is to identify the places where you can put the platform code behind an interface, code that natively, and then code to the interface in Haxe for the rest. That way, you get the fluidity of being able to switch targets and you aren't jumping between layers so often. But this does come with the cost of having to build up a useful interface and really "own your own stack". It's not just-works technology, although it can come close with some of the frameworks.