Haxe: The Good, The Bad, and the Ugly
Haxe will immediately feel familiar to a lot of developers. Take a look at this simple “Hello World” app:
If we run this with
haxe -main HelloWorld --interp we get the output:
$> haxe -main HelloWorld --interp
HelloWorld.hx:4: Hello world!$>
Something a little more complicated from a recent project of mine looks like this:
To anyone that’s worked with TypeScript, C/C++/C#, or Java this looks really familiar. Us Python guys are a little weirded out by insignificant whitespace and curly braces, but its an adjustment I’m willing to make.
So lets take a look at all that Haxe has to offer…
- Haxe is cool
- Being able to compile my interpreted code down to a binary is wicked cool
- The stdlib is pretty robust, and includes target-specific libraries for lower-level integration into your compile target
- Its fast.
- Anyone familiar with “traditional” programming should feel very at home with Haxe
- SDK/shared library creation is a breeze
- Comes with a package manager
haxeliband can install packages from both the
- Unlike Python, threads are not CPU-bound by a GIL
- Threads have built-in communication abstractions through the
readMessagemethods, no need for semaphores or things like that
- Explicit typing is only forced in certain places, like iterators. Types
Dynamiclet you get away with doing the lest amount of typing necessary, but even half the time types aren’t required.
- The stdlib is woefully lacking in documentation
- Third party libraries seem to be rather stale and not updated very often, and third party support for things like databases seems to be lacking other than the support that’s already baked into the stdlib (MySQL, SQLite)
- Due to its esoteric nature there’s not much on the internets about it. Searching StackOverflow is slightly more difficult than when searching for, say, Python
- Adding external (3rd party) packages requires manually editing your build/run parameters to include the library (
haxe -lib <lib> …), which is both annoying and ripe for mistakes
- Generated source code tends to be rather verbose. The
HelloWorldexample up above generated 15 lines of Python for what could be done in two, and 102 lines of C++.
- Maybe its just me, but I hate trailing semicolons in code. Haxe has them. 90% of my compile errors are missed semicolons.
- Haxe has no real HTTP server functionality. While there are 3rd party libraries like
tinkthat help with this, they are unnecessarily complex and their documentation is also lacking.
- Threading is not supported in
--interpmode. Once you introduce threading you have to start compiling to test.
- Types have too few methods. Type
Threadonly has four methods (
readMessage), methods for
active, and others would go a long way.
- Data structures are messy. Haxe has
anonymous structures, but most objects seem to work with the slower un-optimized
anonymous structuresrather than the optimized
- Basic library support for things like
ini, argument parsing and such don’t yet exist (but is also an opportunity to contribute to the Haxe stdlib)
Is Haxe anything more than a novelty? I think so. I think there is a very interesting case to be made for a high-level language that transpiles to other lower-level languages. As I’ve already stated, SDK creation is one of those areas, but also just simplifying a codebase across multiple platforms, especially if those platforms include mobile devices.