| 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. |