←back to thread

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

(fory.apache.org)
66 points chaokunyang | 3 comments | 28 Oct 25 17:58 UTC | HN request time: 0.554s | 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
Show context
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 #
1. 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 #
2. 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.
3. 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.