5 ms·

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 u

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).

revorad 16y ago
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.
chipsy 16y ago
Interesting that you dislike the type inference. I think you may be the first person to say that. I have found it invaluable for refactoring.
- regularfry 16y ago
  Buggy type inference, on the other hand, may well be infuriating. Not that I'm accusing haxe of being buggy, but that's the GP's implication...
  - chipsy 16y ago
    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.
    - abstractbill 16y ago
      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.
    - jdonaldson 16y ago
      This problem will probably get fixed soon. To get an idea of things that Nicholas (the language author) is working on, you can keep tabs on this page: http://haxe.org/com/features http://haxe.org/com/features (e.g. optional structure types) 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.

revorad 16y ago

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.

chipsy 16y ago

Interesting that you dislike the type inference. I think you may be the first person to say that. I have found it invaluable for refactoring.

regularfry 16y ago
Buggy type inference, on the other hand, may well be infuriating. Not that I'm accusing haxe of being buggy, but that's the GP's implication...
- chipsy 16y ago
  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.
  - abstractbill 16y ago
    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.
  - jdonaldson 16y ago
    This problem will probably get fixed soon. To get an idea of things that Nicholas (the language author) is working on, you can keep tabs on this page: http://haxe.org/com/features http://haxe.org/com/features (e.g. optional structure types) 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.