I've been using haxe as a way to make programming to an avm1/ActionScript 2 target (embedded-device Flash Lite, pre-Flash Lite 4) bearable. I'm absolutely delighted Nicolas hasn't stripped out the backend for that target though surely it must not be too widely used these days.
Our devices (I work at Chumby) will soon be AS3-capable but at this point I'd like to stick with Haxe anyway because I've grown to love the language for things like generics, inline methods and it'll be cool to be able to access the Alchemy memory directly from non-C++/Alchemy-compiled code when I can.
Protip: Don't just look at the release version of haxe, there is a ton of cool new stuff in the svn that hasn't yet been wrapped into a release, including a very flexible compile-time code generating macro system.
You work at Chumby! I'm trying to get into some hardware hacking and came across your site just recently. I'd love to talk about it and ask some questions. Can I email you? Or please drop me a note (my email's in profile). Thanks!
I wrote a small application in Haxe earlier this year. The task was to contact a Flash server (FMS) and sync the RSOs. This needed to run as a cron job, so without a browser or a Desktop. That meant Adobe's tools in this regard were not useful at all.
I was able to get a small program working with Haxe, however I figured out that you still need Adobe's runtimes, so it didn't solve our problems. I ended up using Smaxe ( http://smaxe.com/ ), which is a commercial (non OSS) library that allows you to work with all sorts of Flash technology from Java.
I found the whole Haxe system to be intriguing. The Neko VM appears to be quite sophisticated. The idea of writing PHP in another language is certainly appealing, as is developing Flash and ActionScript outside of Adobe's IDE.
Quick suggestion about the website: It would be great to have a feel of the language on the homepage. I.e. I had to dig in in the doc to see how the language felt like (I used the syntax section).
So, a kind of hello world code that compiles in different platforms could be a great way to show the strength of the language.
I agree with this, but the look and feel of the syntax is typical ecmascript, and not that interesting. I think a simple "hello world" is all that is needed.
I have used HaXe for a while - however no where near the level that it could be used for.
It's developed by Nicolas Canesse of MTASC fame as well as the developer of the Neko VM and HaXe which runs on top of it. Excellent and active community and the features are constantly expanding (considering the additions of output targets such as iPhone, PHP, JS, etc).
Well worth a look for any developer (even if you aren't interested in the Flash portion which seems to be the biggest usage area).
Is NekoVM interesting? As you said, using it for Flash is the most interesting part, as it's a good alternative to the official tools, especially on platforms Adobe doesn't like that much. Yet compiling to PHP for the web (page/service) part of it seems oddly wrong to me.
JavaScript/node would be another option, but something more native might pique my interest.
I agree that the PHP portion seems wrong - but it is in active development and I know a lot of people are indeed using that feature - so while it might not be my personal output target of choice, it does get used.
The biggest benefit of all this is a build once, deploy multiple architecture, so if you are a Flash developer, you can also target iPhone or C++ for desktop, or other outputs with slight code changes.
When developing for php or any target, you still need to be aware of some of the quirks:
http://haxe.org/com/quirks
These are familiar to php devs, but maybe less so for people who just want to work with haxe on php platforms.
It should also be noted that there's an active progress for targeting iOS and Android targets with HaXe. So if you're an experienced Android/iOS programmer you may consider lending a hand.
All of justin.tv's Flash code is written in haXe, because I got fed up with Adobe's tools a couple of years ago.
It's a very nice Flash compiler, which makes up for some very poor language design choices imho (for example static typing and type-inference, but the type inference sucks and frequently infers the wrong type).
Really cool to know a big site like justin.tv is using it. Not that I'm a pro hacker, but I had never heard of haXe until today. Given the number of upvotes this submission got, apparently lots of other people didn't know about it either.
It's not buggy. It is a straightforward implementation of structural subtyping. The main flaw of that is that structural subtypes are imprecise and easy to confuse the compiler with. For example:
Sometimes you will write a function signature with an inferred type that manipulates properties x,y,z, expecting to pass in class Foo(which has x,y,z,q,r...). Instead haXe will say something like, "expected Object{x,y,z}, got Foo..." and so you have to add an annotation.
This is a small annoyance, but overall, it's not nearly as bad as Java-style nominal types. And it is not a source of runtime errors - it's a huge preventer.
There are still a few kinks in the generics as well, more complex (but common) method signatures won't work, like this one:
class GenericMap {
static public function map <A, B, C:IFold<A>, D:(ICreateEmpty<B>, IAdd<B>) > ( c : C, f : A -> B ) : D
return c.fold( createEmpty(), function(a,d) return d.add(a) )
}
The haxe compiler is geared to be very quick, and I'm assuming recursive structural subtyping and complex generics might make things too slow.
The compiler is intimately integrated into most haxe workflows... it is used not only for compilation, but it also plays a key role in providing automatic field completions.
And it is not a source of runtime errors - it's a huge preventer.
This is, unfortunately, not the case. We've had bugs go into production at jtv that have been caused by a combination of haXe's inadequate type-inference, and the Flash runtime's type-coercion mechanics. For example, I once did this:
public static function getSwfArg(name, defaultValue=null) {...}
Used elsewhere like this:
if(getSwfArg("is_on_site", false)) {...}
Unfortunately without further type-hints, if the "is_on_site" swf parameter was not present, getSwfArg would magically return the string "false", instead of the boolean false that was passed in. Ugh!
I've spent 6 years doing nothing but Java, and more than that working in various dynamically-typed languages. I'd prefer either of those to what haXe has.
Having said that, again, I like the compiler enough that I put up with this stuff - I use haXe for many of my side projects as well as at jtv.
Just shared the link to this thread on the HaXe mailing list - there are far more experienced users who could give a better understanding of the language and it's uses than I can.
HaXe is a "web" oriented language, so the strength is in the write-once, deploy anywhere style of development. However, another key strength is handling communication between layers in a website... such as between php and javascript, or javascript and swf:
http://haxe.org/doc/remoting
Since each layer is written in the same language, it is simple to write proxies and connection layers between them. It's also easy to update or change these protocols all at once. There are already some great serialization, proxy, and remoting classes in the base library.
I've used haXe since 2007 for Flash game projects. It's a good example of "small language design" in action and cleans up a lot of warts in ECMAScript.
When I started there were unresolved issues making it unpalatable for all Flash projects(e.g. preloader creation), but they have since all been overcome and documented. It still requires some elbow grease to get working.
Not that it negates any of HaXe's abilities.. But JavaScript is also a multiplatform language :-)
It's worth taking a look at though. I have to get over a fear of cross-compiling (like CoffeScript or RJS to JavaScript), largely because I had bad experience debugging such stuff in the past.
haXe and JS are both multiplatform and haXe's syntax is ECMAScript like.
However, haXe is strongly typed. I'm not saying weakly typed language is bad, just another option.
Also, haXe can target JS, so platform-wise it owns a superset of JS's.
interesting but i am not impressed. why can't i just write c++ and compile it? why would i need haxe for? a "standard" language doesn't need to be compiled into other non-standard languages.
i thought this is supposed to be multi platform? i don't see C# (windows) or other languages there? kind of misleading to me, sorry.
Haxe originally start out with support for Flash, JavaScript and Neko (a small VM available for both Lin/Win/Mac, see nekovm.org).
More recent and in-development targets are PHP and C++. I think there is Java and C# somewhere in the sheds, but nothing spectacular yet.
Haxe vs. C++
------------
Pros:
* relatively easy cross-platform communication via remote function calls ("remoting")
* powerful language with many practical constructs (a bit like C++ with boost included.. wait a bit.. :)
* Code sharing between platforms - write once, run on Flash/Servers(neko/php/cpp)/IPhone(cpp)/Browser(js)..
* Automatic type inference (don't write the types, but you still get strict checking)
* Hacker feeling :)
* Possibly many other
Cons:
* Hacker feeling (your manager possibly won't allow it as it is not "Enterprise")
* Generics ("type parameters") are far behind C++ templates.. yet
* Possibly many other
You won't write nuclear simulations in Haxe, but if you are into web/interactive apps, it is worth a peek.
If I am not mistaken, this language's main target is the web. As such it targets both server side programming and client side. It will run on multiple stacks on both sides. Desktop application programming doesn't appear to be the target of this language, ie. the lack of C# or Java.
Primarily I have used it as a custom wrapper around Flash applications being developed by my Flash team. By creating these custom wrappers I can give full access to the filesystem and databases without the Flash guys needing much knowledge of the surrounding development. This is a lot like Zinc is, however gives me a lot more control over what is happening and I can create additional dll's to hook in to to further extend what is going on behind the scenes.
Our devices (I work at Chumby) will soon be AS3-capable but at this point I'd like to stick with Haxe anyway because I've grown to love the language for things like generics, inline methods and it'll be cool to be able to access the Alchemy memory directly from non-C++/Alchemy-compiled code when I can.
Protip: Don't just look at the release version of haxe, there is a ton of cool new stuff in the svn that hasn't yet been wrapped into a release, including a very flexible compile-time code generating macro system.