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

41–50 of 67 posts

Re: A success story for Haxe

#41

Post by jdk »

drawkbox wrote: post #37
jdk wrote: post #12

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

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.

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

Re: A success story for Haxe

#42

Post by jdk »

w-ll wrote: post #30
jdk wrote: post #12

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

I've been following your dev videos on Youtube. It's funny to think I listen to y'all while working on my own games.

Cheers! It's funnier still to hear that anyone watches those. :)

Re: A success story for Haxe

#43

Post by rfrey »

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…

This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was stable... where else?

I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?

Re: A success story for Haxe

#44

Post by joneil »

brianberns wrote: post #34

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!'); } } }

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.

Re: A success story for Haxe

#45

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

Re: A success story for Haxe

#46

Post by [deleted] »

rfrey wrote: post #43
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…

This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was stable... where else? I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?

[deleted]

Re: A success story for Haxe

#47

Post by ousado »

k_roy wrote: post #45

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.

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

Re: A success story for Haxe

#48

Post by ousado »

RussianCow wrote: post #27
yissachar wrote: post #24

Earlier quoted context omitted.

Regarding targeting the web, you can't do this directly with RoboVM, but you can use GWT to do so. This means that you can target Android, iOS, and web with Java. You would have shared code that all platforms could use, and then build the UIs natively. This is pretty much the approach that Google use with Inbox, except they used j2objc instead of RoboVM.

That's true, thanks for pointing that out. Java-based solutions can target the web "for free".

When you take development time into account, GWT doesn't come for free. Yes, it's possible to compile Java to JS via GWT, but the toolchain is prohibitively slow. In contrast, the Haxe compiler is extremely fast.

Re: A success story for Haxe

#49

Post by ousado »

benologist wrote: post #16
RussianCow wrote: post #15

Earlier quoted context omitted.

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?

Of course you have to learn the language the compiler is implemented in when you're hacking the compiler. That's not an inconvenience, it's a tautology.

Re: A success story for Haxe

#50

Post by benologist »

rfrey wrote: post #43
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…

This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was stable... where else? I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?

I don't think it is reasonable to blame me for encountering a bug in their code, the problem is in their code. Please read the success story - the person advocating for it describes plenty of time spent compensating for it for reasons much more diverse than this one example. This is a common experience - mentioned in several comments here too.
Post reply on HN