
A success story for Haxe - curtis
http://nadako.tumblr.com/post/113390739725/a-success-story-for-haxe
======
danso
Shouldn't the title be, "Another success story for Haxe"? I thought the
massive success of Lucas Pope's "Papers, Please" is validation enough of the
framework:
[http://en.wikipedia.org/wiki/Papers,_Please](http://en.wikipedia.org/wiki/Papers,_Please)

(at least it was for me...I was amazed at how fast Pope built and ported a
cross-platform game considering he's a one-man shop...though to be fair, he
was also able to learn Flash and build games for Ludum Dare competitions...so
he's probably an outlier :) )

~~~
nubbee
While Haxe allows you to compile to pretty much everything using the same
language, it doesn't use the same api for every target. Openfl[1], which is
written in Haxe and allows you to use the flash api, compiles to pretty much
anything using 1 codebase. "Papers, please" used openfl to achieve its
portability so I guess it's a success story for openfl as well. Rhymdkapsel is
another great game that uses it.

[1] [http://www.openfl.org/](http://www.openfl.org/)

------
jdonaldson
Learning Haxe is a great way of understanding how certain PL concepts map to
different language implementations. You can write up a simple "hello world"
example for the feature you're interested in, and see what it gets turned into
in the output.

Another interesting thing to look at is the OCaml source for the Haxe compiler
itself.
[https://github.com/HaxeFoundation/haxe](https://github.com/HaxeFoundation/haxe)

At first, I was hesitant to do much with the compiler since I don't know
OCaml. But, I recently forked the source and am making an attempt at a lua
target:
[https://github.com/jdonaldson/haxe/tree/haxe_lua_rb1](https://github.com/jdonaldson/haxe/tree/haxe_lua_rb1)

It's been a great way to learn OCaml, and Lua. If you're interested in
creating your own Haxe target, I'm hoping my commit log will be helpful.

------
jdk
We just released our second game in Haxe on iOS a few weeks ago and we're
releasing the Android version in another 6 weeks. It's a Unity client with
haxe-generated C# code and then javascript and node on the server. There have
definitely been a bunch of hiccups and hitches along the way, but it's been
pretty good overall.

[https://itunes.apple.com/us/app/world-
zombination/id68062469...](https://itunes.apple.com/us/app/world-
zombination/id680624697?mt=8)

~~~
drawkbox
Is it running on IL2CPP Unity? Noticed that it is after Feb 1st and a new
game.

Great looking game and near perfection on gameplay, idea, brand, art, assets,
ui, icon etc. Flawless victory.

~~~
jdk
Thanks! We had actually soft-launched before the cut-off, so we slipped in
before that requirement got put in place. That said, we did just get it
working with IL2CPP last week which was a few days of work for one engineer.
More hiccups encountered but nothing show-stopping (though mostly in dealing
with Unity's peculiarities than anything else).

------
explorigin
I'm in the process of learning Haxe. I hope it becomes more popular since you
can have macros, static type-checking and a shared code-base with one
language. You can have all these things with Javascript but not at the same
time (that I know of).

Here's a port of the jQuery TodoMVC for anyone wanting a quick example of what
a web-target would look like. [https://github.com/explorigin/todomvc-
haxe](https://github.com/explorigin/todomvc-haxe)

~~~
ousado
When you write Javascript, do you mean TypeScript, AtScript, something else?
There's no type checking in JS, and there is no metaprogramming support in JS,
let alone of the quality it can be found in Haxe.

Besides that, the type system of Haxe is far more expressive than those of
most languages that also compile to JS. Ocaml, Scala and Haskell are the
better known languages that are actual competitors in that regard.

~~~
explorigin
Yes. "With Javascript" I mean via Typescript or Flow, you can have some static
type-checking. You can use Sweet.js for macros with Javascript, but you can't
use both of these tools together.

I'm unfamiliar with Ocaml, Scala and Haskell but OK.

------
RussianCow
I'm looking into potentially using Haxe as a way to share code between iOS and
Android. Unfortunately, it doesn't seem like anybody has made a good, open
source Objective-C/Swift target for it yet. (There is a Swift target here[0]
but it hasn't been committed to since October 8 and doesn't seem production-
ready by any means.) I would contribute one myself but I have no experience
with OCaml, and don't currently have time to learn it.

I like the idea of this approach way more than the one that projects like
Xamarin take (build a common runtime on top of each platform) because you
don't incur any runtime overhead, and debugging would (in theory) be much
easier because you can just debug the native language instead of needing to
understand the extra VM layer on top. As a bonus, with Haxe you can also
target the web, which you can't do with Xamarin/RoboVM/RubyMotion/etc.

Has anyone tried anything like this (not necessarily with Haxe) and had
success with it?

[0]: [https://github.com/ralcr/swift-target](https://github.com/ralcr/swift-
target)

Edit: Wording and clarification, added bit about targeting web.

~~~
benologist
I've been using haxe/openfl in production for 1.5 years and wouldn't really
recommend it. Originally cross-platform code was a really good idea very few
people had or executed well and haxe's warts were forgivable, today that's a
capability many languages have without the hassle. I think the only unique
value left in Haxe is outputting Flash.

~~~
jdonaldson
what languages have a platform comparable to OpenFL?

~~~
WoodenChair
If you mean what languages have a near Flash equivalent API, then Dart has
StageXL

[http://www.stagexl.org](http://www.stagexl.org)

~~~
jdonaldson
Hmm, hadn't heard of that one before.

------
reallyRaoul
If you have a critical bone in your body, prepare for a love/hate
relationship. It is so good and yet so bad in various ways. I wrote a few
unpublished games with 2.0 and NME back when (e.g. mzzl).

~~~
dhagz
I agree. I've used haxe, and it's REALLY nice being able to cross-compile from
one codebase, but there were several times it was more difficult than expected
to get things to work. At this point I'd rather use C++ and just compile on
different machines or in VMs. Or, since I'm looking at haxe from a gamedev
perspective, I'd rather use Unity since it targets every platform haxe does,
and has better docs (HaxeFlixel and HaxePunk are great, but apart from basic
tutorials you're sailing without a compass or rudder - but this was about a
year ago).

------
brianberns
The sample program on the Haxe main page demonstrates a complete
misunderstanding of the value of dictionaries. Not exactly inspiring one to
learn more.

    
    
        class Test {
          static function main() {
            var people = [
              "Elizabeth" => "Programming",
              "Joel" => "Design"
            ];
            for (name in people.keys()) {
              var job = people[name];
              trace('$name does $job for a living!');
            }
          }
        }

~~~
joneil
Haha, I was the one that wrote that example for the homepage. It was never
meant to be a comment on the ideal data structures for different use cases.
Rather it's just there to give developers a taste of the syntax: there's more
semicolons and brackets than Python, less explicit typing than Java.

If you have an example of a better code sample for introducing language
syntax, I'd love to see it so I can learn from it.

~~~
brianberns
My point is that if you're going to iterate through the entire dictionary,
there should be a way to get full key-value pairs, so you don't have to look
up the value for each key. There's no need to change the entire example.
Something like this:

    
    
            for ((name, job) in people) {
              trace('$name does $job for a living!');
            }

------
k_roy
We recently adopted it to provide a sane base to our Javascript. Personally, I
LOVE it. It's cleaned up our code so much.

My problem with it is that it seems to have gone somewhat stale. It's been
almost a year since the last update, and at least for the JS target, a number
of the great external libraries never made the hop over to the 3.0 codebase.

~~~
ousado
Development hasn't stalled at all, neither for the JS target nor for most
other targets. The core compiler is being improved constantly, which benefits
all targets, and there have been improvements in the JS code generator, too
(which isn't easy, the code quality has been very high, already).

~~~
k_roy
Oh I definitely have nothing bad to say about Haxe. I was mostly just
referring about some of the external libraries that never made the jump over
from legacy, which could be indicative of developers jumping ship.

You make a great point; just because a project doesn't put out updates once a
week doesn't mean it's stale. There are some other great projects like haproxy
and redis that are clean enough and stable enough that regular updates aren't
necessary.

I guess you sort of grow accustomed to that mentality when dealing with some
other common OSS projects

~~~
jonasmalaco
Development has been quite stable:
[https://github.com/HaxeFoundation/haxe/graphs/contributors](https://github.com/HaxeFoundation/haxe/graphs/contributors)

You should try the nightly builds or compiling straight from Git. They are
stable enough for many purposes (and if you report a bug chances are that its
fix will soon be available) and you can take advantage of new features.

By the way, there's a new release planned for the next weeks.

------
simlevesque
If you want to see another success story using Haxe check out Motion-Twin.

------
Kiro
> When I was doing AS3+Python there was literally NO shared code

What does shared code mean in this context? Can someone give an example?

~~~
RussianCow
Making use of the same bits of code on both the client and server (or whatever
platforms you need to support). So if you have, let's say, some code that
formats relative dates, Haxe allows you to write that code in one language and
reuse it on both the server- and client-side, whereas normally you'd have to
write a separate version of that in Python and in AS3.

~~~
Kiro
Thanks. Is this really a big issue though? How often do you really need shared
code between the server and client? Seems like I'm missing something.

~~~
jonasmalaco
If you have a client and a server, you'll most likely need to handle input or
state twice. You shouldn't trust the client but you also don't your user to
depend exclusively on the server (you want less latency and/or more
informative errors).

