# A hard to form question about Haxe and its nature
**URL:** https://community.haxe.org/t/a-hard-to-form-question-about-haxe-and-its-nature/4719
**Category:** Haxe
**Created:** [December 1, 2025, 6:53pm UTC](https://community.haxe.org/t/a-hard-to-form-question-about-haxe-and-its-nature/4719 "2025-12-01T18:53:03Z")
**Posts on this page:** 1
**Showing post:** 8
### Author:  [@back2dos](https://community.haxe.org/u/back2dos)
#### Post date: [December 2, 2025, 8:16am UTC](https://community.haxe.org/t/a-hard-to-form-question-about-haxe-and-its-nature/4719/8 "2025-12-02T08:16:17Z")
Testing if `v` is an `Array`: `v is Array` … see [Try Haxe!](https://try.haxe.org/#AEc51BE1)
If you want to know if `v` is an `Array` for some given `T` then generally speaking, that is not possible at runtime, because most targets erase parameters at runtime (like Java, that you mentioned before). Then again, this is not something you need for serialization, because you’ll have to introspect every item individually anyway.
> [@methinkus](#):
>
> This makes me think about this duality, on one hand there is Haxe + Hashlink that could be very tightly coupled and allow first class support for many features common in other languages, and on the other Haxe + multi target, with all it’s issues.
Runtime type information doesn’t come for free. Since HashLink is primarily meant for game development, where performance matters and data structures are often tweaked for compactness to achieve better cache locality, I wouldn’t hold my breath for this to happen.
Also Haxe _not_ being strongly coupled to a fat runtime like most managed languages are, is a unique quality of Haxe that is a strength, not a weakness.
> [@methinkus](#):
>
> HashLink is Haxe first runtime, as I understand. So it would make sense for the runtime built specifically to host Haxe, have all the necessary information to resolve any Haxe types at runtime.
Again, HashLink is designed around various performance considerations, like decreasing the overhead of data types that are quite unique to Haxe (e.g. anonymous objects and enums). RTTI is at best orthogonal to that goal, and may even be at conflict with it at times. It’s not a primary concern and it’s not really a good default.
You will also find that Haxe has many compile time features (such as abstract data types) that disappear entirely at runtime. Dragging around all of this is just not practical.
Instead, you should clearly define a problem, determine how much information you can get at compilete time (always preferable) and then see what’s left to close the gap at runtime and you may then have to figure out a platform specific way to get that information, or see how far you can get with the cross platform reflection capabilities:
- [Type - Haxe 4.3.7 API](https://api.haxe.org/Type.html)
- [Reflect - Haxe 4.3.7 API](https://api.haxe.org/Reflect.html)
- [Std - Haxe 4.3.7 API](https://api.haxe.org/Std.html#isOfType)
> [@methinkus](#):
>
> I tried writing some basic code to see how Haxe feels, and I naturally started with a simple serializer.
Perhaps the problem lies herein. Yes, you’ve picked an intersting problem, but it’s not really all that natural. Haxe is a pragmatic language, aimed to solve real world problems, primarily those of a small game studio in Bordeaux, although other community members are using it for other purposes. Building a reflection based serializer is not a real world problem, especially in a language that has one in the standard library: [haxe/std/haxe/Serializer.hx at development · HaxeFoundation/haxe · GitHub](https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/Serializer.hx)
The std serializer has been there since Haxe 1 IIRC, when Haxe was a far less capabable language than it is today. It is comparatively slow and relies on reflection, which on many targets makes the generators output extra RTTI, which - as established above - doesn’t come for free.
These days you will more commonly find serializer libraries that are built via macros at compile time, using compile time type inspection, which has full information and can provide meaningful errors (e.g. if you’re trying to serialize a function, the macro can tell you that that’s not going to happen - that or if the serialization is tied to some stateful connection, it could serialize some ID where the deserialized function will use said ID to perform some form of RPC call).
There’s a number of examples:
1. Binary - hxbit: [GitHub - HeapsIO/hxbit: Haxe Binary serialization and network synchronization library](https://github.com/HeapsIO/hxbit)
2. Binary - tink\_serialize: [GitHub - haxetink/tink\_serialize: Macro based serialization. Fast & compact. Deal with it.](https://github.com/haxetink/tink_serialize)
3. JSON - json2object [GitHub - elnabo/json2object: Type safe Haxe/JSON (de)serializer](https://github.com/elnabo/json2object/)
4. JSON - tink\_json: [GitHub - haxetink/tink\_json: Macro powered JSON.](https://github.com/haxetink/tink_json)
There’s also a bunch of serialization libraries here, all of which are reflection based as far as I could tell at first glance: [Tag: serialization](https://lib.haxe.org/t/serialization/)
* * *
In conclusion I would put it to you that Haxe’s strength lies in the fact that if you want to have behavior that is derived from the structure of the data, then rather than discovering it at runtime and then branching (in essence building an interpreter), you can inspect it at compile time and generate the appropriate code (in essence building a compiler).
And I would really advise you to start with a real world problem and then build some sort of solution from there. Haxe may not even be the best choice. It definitely isn’t if you don’t properly consider how its more advanced and often quite unique features are best leveraged to tackle said problem. If you just try to use it as a dorky version of Java, you definitely will get nowhere 😉
---
_[View the full topic](https://community.haxe.org/t/a-hard-to-form-question-about-haxe-and-its-nature/4719)._