Some targets will have different behaviours regarding null[1], mostly for static language targets; e.g. basic types that are represented by primitives cannot be null when targeting C#, Java, Flash, or C++. Dynamic language targets don't have this issue. (Can be avoided by wrapping your values in Null<T>).
Overflow is normally not handled consistently[2]; it's left up to the target platform to define the overflow behaviour. E.g, JS only has one numeric type (a 64-bit floating point), and can't represent integers over 52-bits. Can be avoided by using Int32 and Int64 classes, but this reduces the code interop if you want to export a library (consumers would need to make use of the Haxe representation of a 64-bit integer).
Arrays aren't fixed sized; if you want this, you need to use Vectors[3], which aren't interface-compatible with Arrays, so you can't use them as a drop-in replacement. (Compare this to Java's Collections API.)
File system access isn't available on every platform, e.g. JS, Flash. If you target Node.js you can use the file system, you just can't use the normal file API, so you need to write stuff specific to each target.
Dates are, as always, a pain to deal with. Timezones aren't supported by the Date class[4]. DateTools.makeUtc() is not available on some platforms[5].
The built-in database API is only accessible on C++, Neko (Haxe-specific bytecode/runtime), and PHP[6]. AND it only seems to support MySQL. This has stymied my ideas about a cross-language multi-DB ORM.
Basically, you have to intimately know the gotchas of every language you target, and if you already know them you may as well write in that language.
Having said all that, Haxe seems to be greatly improving these abstractions with every release; I think given enough time, it will become an amazing tool. I'm starting to use it in place of Python as my "go to" language. For most purposes you can just use a single target; Neko works well for most functionality, but you can always target C++ for "true" cross-platform compatibility and performance, and JS for the browser.
Overflow is normally not handled consistently[2]; it's left up to the target platform to define the overflow behaviour. E.g, JS only has one numeric type (a 64-bit floating point), and can't represent integers over 52-bits. Can be avoided by using Int32 and Int64 classes, but this reduces the code interop if you want to export a library (consumers would need to make use of the Haxe representation of a 64-bit integer).
Arrays aren't fixed sized; if you want this, you need to use Vectors[3], which aren't interface-compatible with Arrays, so you can't use them as a drop-in replacement. (Compare this to Java's Collections API.)
File system access isn't available on every platform, e.g. JS, Flash. If you target Node.js you can use the file system, you just can't use the normal file API, so you need to write stuff specific to each target.
Dates are, as always, a pain to deal with. Timezones aren't supported by the Date class[4]. DateTools.makeUtc() is not available on some platforms[5].
The built-in database API is only accessible on C++, Neko (Haxe-specific bytecode/runtime), and PHP[6]. AND it only seems to support MySQL. This has stymied my ideas about a cross-language multi-DB ORM.
Basically, you have to intimately know the gotchas of every language you target, and if you already know them you may as well write in that language.
Having said all that, Haxe seems to be greatly improving these abstractions with every release; I think given enough time, it will become an amazing tool. I'm starting to use it in place of Python as my "go to" language. For most purposes you can just use a single target; Neko works well for most functionality, but you can always target C++ for "true" cross-platform compatibility and performance, and JS for the browser.
[1] http://haxe.org/manual/types-nullability.html
[2] http://haxe.org/manual/types-overflow.html
[3] http://api.haxe.org/haxe/ds/Vector.html
[4] http://api.haxe.org/Date.html
[5] http://api.haxe.org/DateTools.html
[6] http://api.haxe.org/sys/db/Mysql.html