I've been playing around with Haxe a lot lately and I'm finding it to be a really interesting toolkit/language.

On a whim I decided to see if there were any development jobs around using Haxe and, at least in my area (Toronto) there was zero results. For such a cool toolkit I was surprised to see that nobody seems to be using it (or at least, not hiring for it).

So I was curious, is anyone out there using it professionally? Assuming it's not just my area and it's not used that much outside small projects does anyone have insight on why that might be?

I remember briefly looking at it a while ago and deciding it wasn't viable (for my specific use cases) due to the licensing.

I remember briefly looking at it a while ago and deciding it wasn't viable (for my specific use cases) due to the licensing.

Why? I dislike the GPL license family as much as the next clean-shaven* professional developer, but:

1) the compiler's license is irrelevant since your code is just data to the compiler not linked against it;
2) the standard library that's mixed into your application is all nice and friendly MIT; and
3) the runtime library's license is also irrelevant as you're merely consuming the API.

Recall that GCC is GPL and glibc is LGPL, so if Haxe's licenses were unusable for proprietary software developers, the entirety of the Linux ecosystem would be as well.

* I'm not actually clean shaven.

3) the runtime library's license is also irrelevant as you're merely consuming the API.

I've never seen/evaluated Haxe, but a runtime library running on the LGPL means it's a no-go for certain closed platforms such as PS3/4, XBox 360/One and iOS, since the LGPL says (in simple terms) the app must allow the user running the application to be able to use his own version of the DLL he compiled himself instead of the one shipped with the program.
Which is not possible in those platforms, and hence violates the license.

This is yet another scripting language to learn - which is a turn off for me.

Looking at the information on the web site, the "toolkit" does not seem that impressive to me.

3) the runtime library's license is also irrelevant as you're merely consuming the API.

I've never seen/evaluated Haxe, but a runtime library running on the LGPL means it's a no-go for certain closed platforms such as PS3/4, XBox 360/One and iOS, since the LGPL says (in simple terms) the app must allow the user running the application to be able to use his own version of the DLL he compiled himself instead of the one shipped with the program.Which is not possible in those platforms, and hence violates the license.

That's a weird grey area with the LPGL. I've seen another interpretation about allowing the user freedom to recompile/replace the code within the normal conventions of that platform. If the platform itself forces users to jailbreak, reverse engineer, etc, etc... Then that's not your fault. If the user does reverse engineer your game in order to patch it, your acceptance of the LPGL means you have to condone this user behaviour.

I feel GPL/LGPL are only good for open source projects producing a standalone application, as you get all those additional burdens you have to obey although they are not clearly told.

As I read them some time ago, it seemed opaque with ambiguous backreferencing from LGPL to GPL with certain exceptions, all in lawyer-speak, such that noone really understands it and, as above, different interpretations exist, which makes you wary of it. Also slightly hypocritical how the licence text is copyrighted and you are not allowed to create a derived version (while sometimes exceptions are added, which contradict parts of it and you cant be sure when exactly they apply) and how it is written to allow selling free software to facilitate RS selling tapes back then.

I remember reading the text and thinking when taking it literally it tells 'you have to provide the source code always in exactly the same way as you provide the binary', even though sometimes I was seeing people just telling you to get it from a different place in a different way. If this is really the case, it would be another clause preventing uploading to an appstore.

The last time I looked at Haxe (which, admittedly, was a couple of years ago), the only fully-supported backend was Adobe Flash. And since Flash was already in the process of dying off, that made it pretty much useless, beyond developing for the handful of flash web portals.

Nickelodeon, Disney, TiVo and Electronic Arts are among a number of reputable companies I know that I use Haxe.

Haxe is a statically-typed language (with friendly type inference) that compiles reliably (in my experience) to JavaScript, C++, Neko and Flash. There are newer C#, Java and Python targets that I have not tested as thoroughly.

"Papers, Please", "Game of the Year" by many publications and a BAFTA award-winner, was written with OpenFL. Other libraries for Haxe include NME, Flambe, Snowkit, Kha and others.

While Haxe provides a cross-language build environment, the real usability shines when you have graphics, sound, input and other components unified over multiple technologies. OpenFL supports HTML5, Flash or native desktop/mobile builds, for example.

Here is an article with more details about TiVo's use: http://haxe.org/articles/tivo-and-haxe/

Here are some links:

http://www.openfl.org

http://www.haxeflixel.com

http://www.stencyl.com

http://www.getflambe.com

Here are some questions I've started using before bothering to evaluating the use of any more languages:

1. How much of the AST is available to tools. I'm thinking: Auto-complete tools that don't have to do source analysis, tools for profiling, etc.

2. What does the development environment look like: What kind of immediate debugging tools are available for both stand alone development AND embedded development. Debugging tools that only work on the stand alone code are, frankly, useless.

3. Why should I use this? What problems does it solve that existing mature scripting languages don't solve well. Is it's tool environment that much better? Does it have a significant performance advantage?

4. What does it look like from the embedded perspective. How hard is it to integrate? Are we talking C like bindings? Boost python? How hard is it to control it, how much control do I have over things like the libraries it includes by default, memory management, etc?