Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A success story for Haxe

nadako.tumblr.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: A success story for Haxe

#11

Post by benologist »

jdonaldson wrote: post #7
benologist wrote: post #5

Earlier quoted context omitted.

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.

what languages have a platform comparable to OpenFL?

I don't think there's a drop-in alternative to the Flash API other than OpenFL, but you can achieve the same outcomes in pretty much any language.

If you're just looking for multi-platform stuff, that's almost a minimum requirement now: unity3d, unreal engine, xamarin, javascript etc.

Re: A success story for Haxe

#12

Post by 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...

Re: A success story for Haxe

#13

Post by benologist »

RussianCow wrote: post #8
benologist wrote: post #5

Earlier quoted context omitted.

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.

I think the value of Haxe comes from being able to use one language across platforms, not anything specific to the language itself. Could you speak to the specific "warts" you found while using it? I'm genuinely curious.

My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years:

    The sort operation is not guaranteed to be stable, which
    means that the order of equal elements may not be retained. 
    For a stable Array sorting algorithm, 
    haxe.ds.ArraySort.sort() can be used instead.
Every platform has its own gaps in the API. This is evident in this submission - after the author translated his JavaScript he then had to fix his haxe to work within the subset available to C#.

OpenFL isn't a mature platform and their releases are rushed and buggy. If you download and install their setup process will install the newest version of dependencies and their incomplete documentation will leave you to figure out what versions are actually compatible. Gestures are a pain in the ass with immature and incomplete libraries.

The one thing that makes it worth using - barely - is the decade and a half of ActionScript experience I also have.

Re: A success story for Haxe

#14

Post by elsassph »

benologist wrote: post #5
RussianCow wrote: post #3

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…

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.

Let's be careful not to limit Haxe to OpenFL, which the linked article isn't even using. The article points out that Haxe is a great option for creating portable application logic while the game is using Unity for rendering.

Other uses for Haxe are the JavaScript target which a number of companies are using extensively in the same way you would be using typescript/coffeescript.

Re: A success story for Haxe

#15

Post by RussianCow »

benologist wrote: post #13
RussianCow wrote: post #8

Earlier quoted context omitted.

I think the value of Haxe comes from being able to use one language across platforms, not anything specific to the language itself. Could you speak to the specific "warts" you found while using it? I'm genuinely curious.

My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: The sort operation is not guaranteed to be stable, which means that the order of equal elements may not be retained. For a stable Array sorting algorithm, haxe.ds.ArraySort.sort() can be used ins…

I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".)

Also, if I were to use Haxe for mobile development, it wouldn't be through OpenFL; I would use the native APIs of each system and just write a thin wrapper in Haxe that's common for all platforms. I just want to reuse code, not adopt a completely separate UI toolkit.

Re: A success story for Haxe

#16

Post by benologist »

RussianCow wrote: post #15
benologist wrote: post #13

Earlier quoted context omitted.

My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: The sort operation is not guaranteed to be stable, which means that the order of equal elements may not be retained. For a stable Array sorting algorithm, haxe.ds.ArraySort.sort() can be used ins…

I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".) Also, if I were to use Haxe for mobile development, it wouldn't be through OpenFL; I would use the native APIs of each system and just write a thin wrapper in Haxe that's…

The success story mentions the dev had to learn OCaml to fix bugs in Haxe, other comments here by jdk and reallyRaoul refer to inconveniences too. Elsassph mentions some of the issues are specific to OpenFL not haxe, that's true both ways. I think you can reasonably expect to encounter issues.

Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs?

Re: A success story for Haxe

#17

Post by 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

(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 :) )

Re: A success story for Haxe

#18

Post by jdonaldson »

benologist wrote: post #11
jdonaldson wrote: post #7

Earlier quoted context omitted.

what languages have a platform comparable to OpenFL?

I don't think there's a drop-in alternative to the Flash API other than OpenFL, but you can achieve the same outcomes in pretty much any language. If you're just looking for multi-platform stuff, that's almost a minimum requirement now: unity3d, unreal engine, xamarin, javascript etc.

unity/unreal engine isn't really a fair comparison, you're either requiring a web view plugin (unity), or you're going with emscripten (unity/unreal). I couldn't find evidence of solid support for Xamarin there either.

Haxe has the ability to integrate much more cleanly across all of these platforms imho.

Re: A success story for Haxe

#19

Post by 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

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

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.

Re: A success story for Haxe

#20

Post by jonasmalaco »

RussianCow wrote: post #15
benologist wrote: post #13

Earlier quoted context omitted.

My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: The sort operation is not guaranteed to be stable, which means that the order of equal elements may not be retained. For a stable Array sorting algorithm, haxe.ds.ArraySort.sort() can be used ins…

I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".) Also, if I were to use Haxe for mobile development, it wouldn't be through OpenFL; I would use the native APIs of each system and just write a thin wrapper in Haxe that's…

I've known Haxe for almost 7 years and have been using it extensively in the past 4.

In my experience, inconsistencies between targets and undefined behaviour were common, but most cases have since been removed or documented.

Also, I find it's usually trivial to see how a given Haxe API (be it one in the standard Haxe library or from a third-party lib) maps to native calls.

Personally, the fact everything in the Haxe ecosystem is open-source and has reasonable scale (for instance, the std API by design isn't as big as Java's) is one of the reasons I like it so much. Even though I can't code in Ocaml and modify the compiler itself, I feel that can I solve most time-sensitive issues that might arise (bugs, unexpected behaviour, extending APIs, etc.).

Other reasons I code a lot in Haxe are: code reuse; powerful type system (ADTs, abstracts...); macros; reasonably pleasant syntax (although a bit verbose for my taste).

Post reply on HN