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

31–40 of 67 posts

Re: A success story for Haxe

#31

Post by larsiusprime »

Kiro wrote: post #29
RussianCow wrote: post #26

Earlier quoted context omitted.

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.

Multiplayer games where you need to do client-side game logic and then verify that on the server.

Re: A success story for Haxe

#32

Post by jonasmalaco »

Kiro wrote: post #29
RussianCow wrote: post #26

Earlier quoted context omitted.

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.

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

Re: A success story for Haxe

#33

Post by dhagz »

reallyRaoul wrote: post #4

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

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

Re: A success story for Haxe

#34

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

Re: A success story for Haxe

#35

Post by jdonaldson »

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

It's a simple example, but it's showing a lot of nice things.

The "people" instance is using anonymous syntax for a Map type. Haxe's Map types are actually abstract types: http://haxe.org/manual/types-abstract.html. I doubt many developers are familiar with this type of feature.

For instance, here's a "packed array" implementation that lets me store an array of integers in a fraction of the space usually needed for a standard array type: https://github.com/jdonaldson/packhx Abstract types let me use the same api that standard arrays use (including array accessors), even if the underlying runtime implementation is completely different.

The other nice things going on in the example is the simple for loop using an iterator, and the nice string interpolation. Granted, this is nothing super sophisticated, but it's great to have these same features across all the targets that Haxe supports.

Re: A success story for Haxe

#36

Post by WoodenChair »

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?

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

http://www.stagexl.org

Re: A success story for Haxe

#37

Post by drawkbox »

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.

Re: A success story for Haxe

#39

Post by djur »

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…

Could you explain what's wrong with Array.sort? Lots of languages' standard libraries have unstable sorts, including C. What kind of crashes could be caused by an unstable sort?

Re: A success story for Haxe

#40

Post by sehugg »

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.

I've done this successfully with libGDX/RoboVM for my game Feldspar. (http://feldspargame.com)
Post reply on HN