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

21–30 of 67 posts

Re: A success story for Haxe

#21

Post by jonasmalaco »

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?

I don't do that many UIs at all, so I wouldn't know about that. Even so...

These languages are certainly more mature than Haxe, but I do still expect to find some bugs in their standard libraries (in performance or security).

And when you factor in third-party libraries, the answer is always "yes you do expect to encounter bugs" independent of the language. For me, programming is in great part reading and fixing other people's code, and I still think most of them are much more skilled than me.

Re: A success story for Haxe

#22

Post by MetaCosm »

danso wrote: post #17

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 compe…

Holy crap, had no idea it was Haxe. That is a great success story (and fun game).

Re: A success story for Haxe

#23

Post by RussianCow »

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?

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

No, but I'd wager that I would spend more time re-writing the app for each native language than I would finding the inconsistencies in Haxe. (And either way, each platform has its own nuances that you have to know whether or not you use Haxe.) For the record, you'd have the same issues with solutions like Xamarin. The whole thing is a trade-off, and I have a (well-supported) hypothesis that the benefits of a (semi-)shared codebase is worth the cost of learning these nuances and inconsistencies.

Re: A success story for Haxe

#24

Post by yissachar »

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…

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.

Re: A success story for Haxe

#26

Post by RussianCow »

Kiro wrote: post #25

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

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.

Re: A success story for Haxe

#27

Post by RussianCow »

yissachar wrote: post #24
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…

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

Re: A success story for Haxe

#28

Post by nubbee »

danso wrote: post #17

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 compe…

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/

Re: A success story for Haxe

#29

Post by Kiro »

RussianCow wrote: post #26
Kiro wrote: post #25

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

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.

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.

Re: A success story for Haxe

#30

Post by w-ll »

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.
Post reply on HN