I've had my eye on Haxe for a long time, and the language has a lot of features that I like - it's cross-paradigm: primarily OO, but good support for functional

I've had my eye on Haxe for a long time, and the language has a lot of features that I like - it's cross-paradigm: primarily OO, but good support for functional programming; plus, macros are amazing and can extend the language to do whatever you want. The project that made me see its potential was "Haxe-WavPack-Decoder", an audio decoder for the WavPack file format. It targets Neko, C++, C#, Java and Javascript. Imagine using Haxe to write reference implementations for file formats (or anything, really), then spitting out implementations for any other target language, so you could include it in a project using any runtime of your choosing. The problems I see are: * The language itself is not a high-level wrapper for each platform/target, so you still need to write different code for each platform. (OpenFL/Lime does a great job at handling this for you for games) * The compiled output might have surprising runtime characteristics. For example, I tried writing an audio rendering app where I targeted C++, and had a naive two-dimensional array (a Vector of Vectors of Floats). When I tried retrieving an inner array, it would attempt to cast the array and its entire contents. This happened every time the array was accessed, and it was accessed multiple times per second. When I flattened the arrays to a single array and used a calculated index, it reduced the processing time from ~30mins to ~5mins. * You can't necessarily make use of each target language's strengths. For example, I think the Java target does not support annotations. * If you want to make use of platform libs/tech, you'll need to define externs for each lib. (There's some efforts to use a TypeScript->Haxe converter to convert all of the DefinitelyTyped definitions to externs, so the JS target is looking promising.) * It seems like a lot of developers come from a Flash/ActionScript background, so there's lots of ports of AS libs with documentation that just says "See the AS lib documentation". This is not helpful for general developers. * Due to having so many use-cases, it's very hard to share knowledge for "Haxe" - are you looking for info on Haxe for games on desktop, or Haxe for games on HTML5, or Haxe for webapps on PHP, or Haxe for webapps on NodeJS...? This is a tribute to its versatility, but it means the developer mindshare gets splintered into separate tribes. * Due to targeting other languages, you kind of have to be an expert in that language/platform already, which means you need to translate from the target language to Haxe in your head. * Since macros can extend the language to do anything else, libraries will splinter based on capabilities and implementations of those capabilities. Some libraries might use an "Optional" macro, some might use "Maybe", and they'll do roughly the same thing but be incompatible. * I believe libraries written in Haxe can only be distributed as source code, limiting commercial investment in developing libs. (Although, JS also has this problem but doesn't seem to suffered.) * Still has nulls. :( It does make some efforts to make developers treat nullable values differently, but it seems inconsistent (and probably dependent on target).