Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: