I sped up serde_json strings by 20%

A blog post on speeding up Rust’s `serde_json` string handling by 20% quickly widens into a debate over JSON support in Rust: some argue that `serde` and `serde_json` are bloated, slow to compile, and should be part of the standard library, while others counter that their dependency footprint is modest and that keeping them as external crates allows faster, independent evolution. Commenters compare Rust’s build sizes and dependency trees to languages like Go, Python, and C#, weighing convenience, compile times, and security risks of large transitive dependency graphs. There is also concern about the safety of low-level UTF‑8 parsing tricks and appreciation for technical write‑ups that show failed attempts and reasoning, not just final performance wins.

Performance Improvements in serde_json

  • Discussion centers on a ~20% speedup in JSON string handling in serde_json.
  • Many see this as an example of Rust’s ecosystem (especially core crates) evolving quickly, independent of the compiler release cycle.
  • Some commenters emphasize the value of optimization work, but a few worry about correctness and want extensive fuzzing, especially for UTF‑8 edge cases.

Size, Dependencies, and Build Artifacts

  • One commenter claims serde_json leads to ~3 GB of dependencies; multiple others reproduce small test projects and measure ~70–80 MB in target/, concluding the 3 GB figure is likely incorrect or conflating multiple projects, IDE artifacts, or stale builds.
  • It’s noted that serde_json itself has very few direct dependencies and is small on crates.io; bloat is mostly from generated code, debug info, and accumulated artifacts.
  • Several people remark that Rust debug builds and target dirs get very large; cargo clean often frees many GB, partly due to stale artifacts and very verbose debug info.

Comparisons to Other Languages

  • A small Rust+serde example is compared to a Go equivalent:
    • Rust build: tens of MB of artifacts, seconds to build.
    • Go build: a few MB of artifacts, fractions of a second.
  • Some argue this makes Rust look “bloated”; others counter that this is mostly build-time overhead, not final binary size.

Should JSON Be in the Standard Library?

  • One side: JSON is ubiquitous; needing a third‑party crate for something so basic is seen as a weakness and a potential supply‑chain risk.
  • Other side: keeping JSON out of std avoids long‑term maintenance burden for a possibly transient format, keeps stdlib lean, and allows independent evolution; adding serde_json via Cargo is considered trivial.
  • There is debate over whether languages with big standard libraries (Python, Go, C#) set a better precedent than Rust’s “small std, rich ecosystem” model.

Dependency Trees and Ecosystem Maturity

  • Some view Rust’s deep dependency trees as a security and maintainability concern, especially for web stacks pulling in hundreds of crates.
  • Others argue this is a trade‑off enabled by good package management, encouraging code reuse and small, well‑factored libraries, analogous to ecosystems like Node.js.