←back to thread

Show HN: Apache Fory Rust – 10-20x faster serialization than JSON/Protobuf

(fory.apache.org)
66 points chaokunyang | 5 comments | 28 Oct 25 17:58 UTC | HN request time: 0.217s | source

Serialization framework with some interesting numbers: 10-20x faster on nested objects than json/protobuf.

  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/rust
1. tnorgaard ◴[28 Oct 25 20:40 UTC] No.45738849[source]▶
I wish we would focus on making tooling better for W3C EXI (Binary XML encoding) instead of inventing new formats. Just being fast isn't enough, I don't see many using Aeron/SBT, it need a ecosystem - which XML does have.
replies(2): >>45739088 #>>45743030 #
2. stmw ◴[28 Oct 25 20:58 UTC] No.45739088[source]▶
I am not sure if W3C EXI, or ASN.1 BER or something else is better, but agree that using DOP (rather than OOP) design principles is the right answer -- which means focusing on the encoding first, and working backwards towards the languages / clients.
replies(2): >>45743052 #>>45743327 #
3. chaokunyang ◴[29 Oct 25 05:40 UTC] No.45743030[source]▶
Binary XML encoding (like W3C EXI) is useful in some contexts, but it’s generally not as efficient as modern binary serialization formats. It also can’t naturally express shared or circular reference semantics, which are important for complex object graphs.

Fory’s format was designed from the ground up to handle those cases efficiently, while still enabling cross‑language compatibility and schema evolution.

4. chaokunyang ◴[29 Oct 25 05:43 UTC] No.45743052[source]▶
DOP is very interesting, I like this idea too — most DOP approaches are implemented via an IDL, which is another valid direction. I plan to support that in Fory. I want to give users the freedom to choose the model that works best for them.
5. chaokunyang ◴[29 Oct 25 06:29 UTC] No.45743327[source]▶
DOP is great, but there’s always a gap between DOP and OOP. That gap is where Fory comes in. Right now, Fory takes an OOP‑first approach, but next we’ll add a DOP path by introducing an optional IDL — bridging the two styles. My goal is for the IDL to also support optional OOP‑style expressiveness, so teams can choose the balance that fits their needs.