Posted by chaokunyang 2 days ago
  Technical approach: compile-time codegen (no reflection), compact binary protocol with meta-packing, little-endian layout optimized for modern CPUs.
  Unique features that other fast serializers don't have:
  - Cross-language without IDL files (Rust ↔ Python/Java/Go)
  - Trait object serialization (Box<dyn Trait>)
  - Automatic circular reference handling
  - Schema evolution without coordination
  Happy to discuss design trade-offs.
  Benchmarks: https://fory.apache.org/docs/benchmarks/rustApache Fory, on the other hand, has its own wire‑stream format designed for sending data across processes or networks. Most of the code is focused on efficiently converting in‑memory objects into that stream format (and back) — with features like cross‑language support, circular reference handling, and schema evolution.
Fory also has a row format, which is a memory format, and can complement or compete with Arrow’s columnar format depending on the use case.
https://fory.apache.org/blog/fury_blazing_fast_multiple_lang...
But flatbuffers is _much_ faster than protobuf/json:
We haven’t tested FlatBuffers vs. Fory for Rust yet, but we plan to.
It’s also worth noting the focus is a bit different: FlatBuffers is great for certain constrained scenarios (e.g., games, embedded), while Fory is a more general‑purpose serialization framework with features like cross‑language object graph support, circular reference handling, and schema evolution.
The AGENTS.md file was added only recently. Its original purpose wasn’t to hand code generation entirely to an AI, but rather to use AI as a pair‑programming debugger — for example, having it walk through tricky binary parsing issues byte‑by‑byte. Serialization in a compact binary format can be hard to debug, and AI can sometimes save hours by quickly pinpointing structural mismatches.
That said, serialization is a fundamental piece of infrastructure, so we remain conservative: any AI‑assisted changes go through the same rigorous review and test process as everything else. As technology evolves, I think it’s worth exploring new tools — but with care.
    use fory::{Fory, ForyObject};
    #[derive(ForyObject, Debug, PartialEq)]
    struct Struct {
        nan: f32,
        inf: f32,
    }
    fn main() {
        let mut fory = Fory::default();
        fory.register::<Struct>(1).unwrap();
        let original = Struct {
            nan: f32::NAN,
            inf: f32::INFINITY,
        };
        dbg!(&original);
        let serialized = fory.serialize(&original).unwrap();
        let back: Struct = fory.deserialize(&serialized).unwrap();
        dbg!(&back);
    }
     cargo run
       Compiling rust-seed v0.0.0-development (/home/random-code/fory-nan-inf)
        Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.28s
         Running `target/debug/fory-nan-inf`
    [src/main.rs:17:9] &original = Struct {
        nan: NaN,
        inf: inf,
    }
    [src/main.rs:22:9] &back = Struct {
        nan: NaN,
        inf: inf,
    }
I do really like that is broad support out of the box and looks easy to use.
For Python I still prefer using dill since it handles code objects.
https://github.com/apache/fory/tree/main/python#serialize-lo...
When serializing code objects, pyfory is 3× higher compression ratio compared cloudpickle
And pyfory also provide extra security audit capability to avoid maliciously deserialization data attack.