This is just a quick post regarding my experiences using the Haxe programming language over the last couple of days to make a simple 2D game.
On the surface Haxe looks like a great tool, being a language that allows you to write the code once and then deploy to a number of platforms, including Flash, HTML5, native code (via C++), etc. These days a small developer would be taking a bit of a risk to write for just one platform so if this works well, it could be a great asset. The syntax is the familiar C++/Java/C# style so really it’s not so much a new language as a new set of libraries and a few slightly different keywords plus the tool chain to match. The learning curve therefore is pretty narrow for most programmers with experience of a C++ style language.
However where it starts to fall down is the area of general maturity. String handling is minimal, with there being no sprintf function or format method to create non-trivial text output. The type casting syntax is ugly and throws a pretty vague exception when it fails. In fact all the error messages are fairly curt and unhelpful. IDE support is currently poor, with FlashDevelop struggling to handle stepping through the code. Installation is primitive, expecting to put its tools in a directory off the root of your drive so that its command line library installation tool can write directly to that directory. (This is an awful decision for anybody who wants to make standalone per-project environments, or has a multi-user system, or has security restrictions regarding where they can install to, etc.) The standard libraries are very sparse, and although you have access to platform specific libraries, that’s not much use if you want portable code, and the wrappers aren’t fully documented yet anyway.
And that touches on the biggest problem, being that the platform independence isn’t quite there yet. String encoding differs depending on the back-end, which is bound to cause problems for internationalisation. Code that compiles on one platform may not compile on another, because there is platform-specific code that doesn’t get tested until you try a build. Code that compiles on 2 platforms may raise an error on one and not the other when executing code that didn’t appear to be platform-specific. (My game works perfectly in the Flash build but crashes with an ‘Invalid Cast’ pop-up on the native Windows build.) Code that runs on 2 platforms may act differently on both – my rendered text (using HaxePunk) appears differently on the Windows build to the Flash build. There are so many different parts between your code and the final build for each platform that it’s not surprising that one part or other often malfunctions.
You can tell that a massive amount of work has been done to get the same Haxe code creating different output code for each platform and wiring it up to the various different capabilities. But some of this wiring and rewiring isn’t fully working yet and the danger is that you’ll discover a problem quite some way after the project begins and end up faced with few options for fixing it. As such I can’t recommend Haxe as a “write once, deploy anywhere” portable language. With some platforms exhibiting runtime errors that others do not, you get the worst of both dynamically and statically typed languages: you have to exhaustively test every line of your code, but you’re paying a syntactic price to please the compiler as well. It would seem wiser to pick whichever one of the two routes that you prefer and enjoy the benefits as well as the disadvantages.
I hope that Haxe continues to improve because I can see it being useful to some people. However based on my experiences with it, I would say the best route to platform independence is still to write code that targets a particular virtual machine, whether that be Java, Python, .NET, or Flash.