Beyond JSON: TOML, YAML, MessagePack, bincode, and CSV with Serde

21 min read

In the Node.js world, JSON is the default and everything else needs a separate library: js-yaml for YAML, @iarna/toml for TOML, csv-parse for CSV, @msgpack/msgpack for MessagePack. Each ships its own API, its own type story, and its own quirks. Serde flips this: you derive Serialize and Deserialize once, then plug in a different format crate to read or write the same data as TOML, YAML, MessagePack, a binary blob, or CSV rows. This page shows the same struct travelling through all five formats.

Quick Overview

Serde separates your data types from the wire format. Your structs implement the Serialize and Deserialize traits via #[derive]; a format crate (toml, serde_norway, rmp-serde, bincode, csv) knows how to turn that trait-driven description into bytes and back. Adding a new format to your program means adding a crate and calling its to_string / from_str (or to_vec / from_slice) — your type definitions do not change at all. For a TypeScript developer this is the payoff: one set of annotations, every format for free.

Note: This page assumes you already know the JSON basics from serde-basics.md and how #[derive(Serialize, Deserialize)] works from derive-serialize.md. The architecture that makes one derive work across all formats is explained in serde-intro.md.

TypeScript/JavaScript Example

In Node.js, each format is a different package with a different shape. Here is the same configuration object serialized to four text formats and one binary format, the way you would actually do it:

1
// npm install js-yaml @iarna/toml @msgpack/msgpack
2
import * as YAML from "js-yaml";
3
import * as TOML from "@iarna/toml";
4
import { encode, decode } from "@msgpack/msgpack";
5

6
interface ServerConfig {
7
  name: string;
8
  port: number;
9
  workers: number;
10
  tls: boolean;
11
  allowedOrigins: string[];
12
}
13

14
const config: ServerConfig = {
15
  name: "api-gateway",
16
  port: 8443,
17
  workers: 8,
18
  tls: true,
19
  allowedOrigins: ["https://app.example.com", "https://admin.example.com"],
20
};
21

22
// JSON — built in
23
const json: string = JSON.stringify(config);
24

25
// YAML — js-yaml: returns `any` on load, no type checking
26
const yamlText: string = YAML.dump(config);
27
const fromYaml = YAML.load(yamlText) as ServerConfig; // cast is unchecked
28

29
// TOML — @iarna/toml: again `any`, again an unchecked cast
30
const tomlText: string = TOML.stringify(config as any);
31
const fromToml = TOML.parse(tomlText) as unknown as ServerConfig;
32

33
// MessagePack — binary, returns Uint8Array; decode() is `unknown`
34
const packed: Uint8Array = encode(config);
35
const fromMsgpack = decode(packed) as ServerConfig; // cast is unchecked

Notice the recurring pattern: each library has a different method name (dump/load, stringify/parse, encode/decode), and every load/parse/decode hands you any or unknown that you cast with as. That cast is a compile-time fiction — nothing validates that the parsed bytes actually match ServerConfig at runtime. CSV is worse still: most Node CSV libraries give you arrays of strings and you convert each field by hand.

Rust Equivalent

First, add the format crates. cargo new selects the newest stable edition automatically (the current stable toolchain is Rust 1.96.0 on the 2024 edition):

1
cargo new config_formats
2
cd config_formats
3
cargo add serde --features derive
4
cargo add serde_json
5
cargo add toml
6
cargo add serde_norway        # maintained successor to the deprecated serde_yaml
7
cargo add rmp-serde           # MessagePack
8
cargo add bincode@2 --features serde
9
cargo add csv

That produces these dependencies in Cargo.toml:

1
[dependencies]
2
bincode = { version = "2", features = ["serde"] }
3
csv = "1.4.0"
4
rmp-serde = "1.3.1"
5
serde = { version = "1.0.228", features = ["derive"] }
6
serde_json = "1.0.150"
7
serde_norway = "0.9.42"
8
toml = "1.1.2"

Now define the struct once and run it through every format in src/main.rs:

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize, PartialEq)]
4
struct ServerConfig {
5
    name: String,
6
    port: u16,
7
    workers: u32,
8
    tls: bool,
9
    allowed_origins: Vec<String>,
10
}
11

12
fn main() {
13
    let cfg = ServerConfig {
14
        name: "api-gateway".to_string(),
15
        port: 8443,
16
        workers: 8,
17
        tls: true,
18
        allowed_origins: vec![
19
            "https://app.example.com".to_string(),
20
            "https://admin.example.com".to_string(),
21
        ],
22
    };
23

24
    // --- TOML (text) ---
25
    let toml_text = toml::to_string(&cfg).unwrap();
26
    println!("=== TOML ===");
27
    print!("{toml_text}");
28
    let toml_back: ServerConfig = toml::from_str(&toml_text).unwrap();
29
    println!("toml round-trip equal: {}", toml_back == cfg);
30

31
    // --- YAML (text) ---
32
    let yaml_text = serde_norway::to_string(&cfg).unwrap();
33
    println!("=== YAML ===");
34
    print!("{yaml_text}");
35
    let yaml_back: ServerConfig = serde_norway::from_str(&yaml_text).unwrap();
36
    println!("yaml round-trip equal: {}", yaml_back == cfg);
37

38
    // --- MessagePack (binary) ---
39
    let mp: Vec<u8> = rmp_serde::to_vec(&cfg).unwrap();
40
    println!("=== MessagePack ===");
41
    println!("msgpack bytes: {}", mp.len());
42
    let mp_back: ServerConfig = rmp_serde::from_slice(&mp).unwrap();
43
    println!("msgpack round-trip equal: {}", mp_back == cfg);
44

45
    // --- bincode (binary) ---
46
    let config = bincode::config::standard();
47
    let bin: Vec<u8> = bincode::serde::encode_to_vec(&cfg, config).unwrap();
48
    println!("=== bincode ===");
49
    println!("bincode bytes: {}", bin.len());
50
    let (bin_back, _consumed): (ServerConfig, usize) =
51
        bincode::serde::decode_from_slice(&bin, config).unwrap();
52
    println!("bincode round-trip equal: {}", bin_back == cfg);
53
}

Real output from cargo run:

1
=== TOML ===
2
name = "api-gateway"
3
port = 8443
4
workers = 8
5
tls = true
6
allowed_origins = ["https://app.example.com", "https://admin.example.com"]
7
toml round-trip equal: true
8
=== YAML ===
9
name: api-gateway
10
port: 8443
11
workers: 8
12
tls: true
13
allowed_origins:
14
- https://app.example.com
15
- https://admin.example.com
16
yaml round-trip equal: true
17
=== MessagePack ===
18
msgpack bytes: 69
19
msgpack round-trip equal: true
20
=== bincode ===
21
bincode bytes: 68
22
bincode round-trip equal: true

The struct never changed. Each format crate exposes the same two-verb vocabulary — text formats use to_string / from_str, binary formats use to_vec / from_slice — and every from_* returns a fully-typed ServerConfig, not an any you have to trust. The round-trip equal: true lines come from PartialEq, proving the data survived the trip intact.

Detailed Explanation

Let’s unpack each format and the one or two lines that drive it.

TOML — toml::to_string(&cfg) / toml::from_str(&text). TOML (“Tom’s Obvious Minimal Language”) is the format Rust itself uses for Cargo.toml, so it is the natural choice for human-edited config. The API mirrors serde_json exactly: to_string, to_string_pretty, from_str. Scalars become key = value; a Vec becomes an inline array; a nested struct becomes a [table] section. One structural rule matters: the top level of a TOML document must be a table (a struct or map), never a bare array or scalar — see Common Pitfalls.
YAML — serde_norway::to_string(&cfg) / serde_norway::from_str(&text). YAML is whitespace-significant and common in Kubernetes, CI pipelines, and Docker Compose. The widely-cited serde_yaml crate was deprecated and archived by its author in 2024; serde_norway is a drop-in maintained fork with the identical API, which is why this guide uses it. The output starts directly with name: — by default it emits no --- document-start marker.
MessagePack — rmp_serde::to_vec(&cfg) / rmp_serde::from_slice(&bytes). MessagePack is a compact binary format (“like JSON, but fast and small”). Because it is binary, you serialize to Vec<u8> (not String) and deserialize from &[u8]. Here the same data is 69 bytes versus JSON’s 131 — roughly half. rmp-serde is the Serde-integrated implementation; the crate name comes from “rust messpack”.
bincode — bincode::serde::encode_to_vec(&cfg, config) / bincode::serde::decode_from_slice(&bin, config). bincode is a Rust-native binary format optimized for Rust-to-Rust communication (caches, IPC, on-disk snapshots). Version 2.x takes an explicit configuration value (bincode::config::standard()) that fixes the integer encoding and byte order, and its decode_from_slice returns a tuple (value, bytes_consumed). The bincode::serde:: path is what bridges bincode to Serde-derived types; it is gated behind the serde feature you enabled with cargo add bincode@2 --features serde.
PartialEq in the derive. Adding PartialEq lets us write toml_back == cfg. It has nothing to do with Serde — it is just how we assert each round-trip preserved the value.

Every format above reads the same #[derive(Serialize, Deserialize)]. That is the whole point of Serde’s design: the format crate and your type never know about each other directly — they meet through Serde’s data model.

Key Differences

Format	Crate	Text/Binary	Serialize / Deserialize	Typical use
JSON	`serde_json`	text	`to_string` / `from_str`	HTTP APIs, config, logs
TOML	`toml`	text	`to_string` / `from_str`	Human-edited config (`Cargo.toml`)
YAML	`serde_norway`	text	`to_string` / `from_str`	Kubernetes, CI, Compose
MessagePack	`rmp-serde`	binary	`to_vec` / `from_slice`	Compact wire transfer, caches
bincode	`bincode` (v2)	binary	`encode_to_vec` / `decode_from_slice`	Rust↔Rust IPC, snapshots
CSV	`csv`	text	`Writer::serialize` / `Reader::deserialize`	Tabular data, spreadsheets

A few conceptual points a TypeScript developer should internalize:

One derive, every format. In Node you reach for a different library per format, each with its own type-erased any. In Rust the type carries the serialization logic, and formats are interchangeable consumers of it. Swapping JSON for MessagePack in a function is often a one-line change.
Binary formats use bytes, not strings. to_vec/encode_to_vec return Vec<u8>; you cannot println!("{}") a MessagePack blob as text. This is a hard type-level distinction Rust enforces, unlike JavaScript where a Uint8Array and a string blur together at the edges.
Self-describing vs. schema-coupled. JSON, TOML, YAML, and MessagePack are self-describing — the bytes contain field names (or at least structure), so a slightly different reader can still parse them. bincode’s compact form is positional: it stores values in field order with no names, which is smaller but means producer and consumer must agree on the exact layout. MessagePack offers both modes (see Pitfalls).
CSV is row-shaped, not tree-shaped. JSON/TOML/YAML/MessagePack represent arbitrary nested trees. CSV represents a flat table: a header row plus data rows. A struct maps cleanly to a row only when all its fields are scalars — nesting a struct inside another and writing it as CSV is an error, not silent flattening.
TOML and YAML are not interchangeable for everything. TOML insists the root is a table and has no concept of a top-level array document; YAML is happy with a top-level sequence. Pick the format to fit the data shape, not the other way around.

Common Pitfalls

Reaching for the deprecated `serde_yaml`

Most YAML tutorials and older answers tell you to cargo add serde_yaml. That crate was deprecated and archived by its maintainer in 2024 and no longer receives fixes. Use serde_norway instead — it is a maintained fork with the same module-level functions (to_string, from_str, to_writer, from_reader), so existing examples work after a rename:

1
// Old (deprecated, unmaintained):
2
// let text = serde_yaml::to_string(&cfg).unwrap();
3

4
// Current:
5
let text = serde_norway::to_string(&cfg).unwrap();

TOML’s top level must be a table

TOML documents are key/value tables at the root. Trying to serialize a bare Vec (or any non-map) at the top level fails. This compiles but errors at runtime:

1
use serde::Serialize;
2

3
#[derive(Serialize)]
4
struct Item {
5
    id: u32,
6
    label: String,
7
}
8

9
fn main() {
10
    let items = vec![
11
        Item { id: 1, label: "a".into() },
12
        Item { id: 2, label: "b".into() },
13
    ];
14
    // runtime error: TOML's root must be a table, not an array
15
    match toml::to_string(&items) {
16
        Ok(s) => println!("{s}"),
17
        Err(e) => println!("error: {e}"),
18
    }
19
}

The real output from cargo run:

1
error: unsupported array type

The fix is to wrap the array in a struct field, e.g. struct Catalog { items: Vec<Item> }, which serializes the array under an [[items]] array-of-tables. JSON and YAML have no such restriction — only TOML requires a table at the root.

CSV cannot represent nested structs

CSV is flat. If a struct field is itself a struct (or a Vec/HashMap), the csv crate cannot lay it out as columns and refuses when it tries to write the header. This compiles but errors at runtime:

1
use serde::Serialize;
2

3
#[derive(Serialize)]
4
struct Address {
5
    city: String,
6
    zip: String,
7
}
8

9
#[derive(Serialize)]
10
struct Person {
11
    name: String,
12
    address: Address, // nested struct: CSV has no column layout for this
13
}
14

15
fn main() {
16
    let p = Person {
17
        name: "Ada".into(),
18
        address: Address { city: "London".into(), zip: "EC1A".into() },
19
    };
20
    let mut wtr = csv::Writer::from_writer(vec![]);
21
    match wtr.serialize(&p) {
22
        Ok(()) => println!("ok"),
23
        Err(e) => println!("error: {e}"),
24
    }
25
}

The real output from cargo run:

1
error: CSV write error: cannot serialize Address container inside struct when writing headers from structs

Keep CSV records flat: use only scalar fields (String, numbers, bool). If you need nesting, flatten it manually (e.g. city: String, zip: String directly on Person) or choose a tree format like JSON.

MessagePack: compact (array) form drops field names

rmp_serde::to_vec produces the compact encoding, which stores struct fields positionally as an array — field names are not written. That is smaller, but it means the decoder must use the exact same field order. to_vec_named writes a map with field names, which is larger but order-independent and interoperable with other MessagePack libraries that expect named fields. Mixing them silently scrambles data rather than erroring:

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Serialize)]
4
struct V1 {
5
    a: u32,
6
    b: u32,
7
    c: u32,
8
}
9

10
// Same fields, declared in a DIFFERENT order:
11
#[derive(Debug, Deserialize)]
12
struct V2 {
13
    c: u32,
14
    b: u32,
15
    a: u32,
16
}
17

18
fn main() {
19
    let v1 = V1 { a: 1, b: 2, c: 3 };
20

21
    // Compact: positions are matched, names ignored -> WRONG mapping
22
    let compact = rmp_serde::to_vec(&v1).unwrap();
23
    let from_compact: V2 = rmp_serde::from_slice(&compact).unwrap();
24
    println!("compact -> {from_compact:?}");
25

26
    // Named: fields matched by name -> correct
27
    let named = rmp_serde::to_vec_named(&v1).unwrap();
28
    let from_named: V2 = rmp_serde::from_slice(&named).unwrap();
29
    println!("named   -> {from_named:?}");
30
}

The real output from cargo run:

1
compact -> V2 { c: 1, b: 2, a: 3 }
2
named   -> V2 { c: 3, b: 2, a: 1 }

The compact decode put 1 into c purely by position — no error, just wrong data. Use to_vec_named whenever the reader and writer might disagree on field order, or when talking to a non-Rust MessagePack consumer.

bincode: decode with the same config you encoded with

bincode 2.x makes the configuration explicit, and it is not stored in the bytes. If you encode with standard() (variable-length integers) and decode with with_fixed_int_encoding(), the bytes are misinterpreted. Always thread the same config value through both calls:

1
let config = bincode::config::standard();
2
let bytes = bincode::serde::encode_to_vec(&value, config).unwrap();
3
// Must decode with the SAME config:
4
let (decoded, _len): (MyType, usize) =
5
    bincode::serde::decode_from_slice(&bytes, config).unwrap();

This is also why bincode is best for Rust-to-Rust links you control end to end, not as a public interchange format.

Best Practices

Match the format to the job. Human-edited config → TOML (or YAML if your platform expects it). Public/browser-facing APIs → JSON. Bandwidth-sensitive service-to-service traffic → MessagePack. Rust-only caches, snapshots, or IPC where you own both ends → bincode. Tabular exports for spreadsheets → CSV.
Use serde_norway, not serde_yaml. The latter is deprecated; the former is the maintained drop-in replacement with the same API.
Prefer to_vec_named for MessagePack across boundaries. The few extra bytes buy field-name interoperability and immunity to field-reordering bugs. Reserve the compact to_vec for internal, version-locked links.
Pin bincode to 2.x with the serde feature. That is the established, maintained release line for Serde integration (cargo add bincode@2 --features serde). Store the config value once and reuse it for both encode and decode.
Keep CSV records flat. Use scalar fields only. For optional columns, prefer Option<T> plus the csv reader’s flexible handling, and lean on Serde attributes like #[serde(rename)] to match header names — see attributes.md.
Read from bytes/readers for large inputs. Text crates offer from_reader/to_writer and the binary crates work directly on &[u8]; streaming avoids buffering a whole file as a String. Performance trade-offs (borrowing, zero-copy, buffer reuse) are covered in performance.md.
Let the same struct serve every format. Define your data types once and switch formats at the call site. Resist duplicating types per format — that defeats Serde’s central advantage.

Real-World Example

A common production need is a config loader that accepts the same settings as JSON, TOML, or YAML and picks the parser by file extension — so ops can write config.yaml while a test fixture uses config.json, all loading into one typed struct. This complete src/main.rs writes the config in three formats, loads each back, and returns a typed error for an unsupported extension:

1
use serde::{Deserialize, Serialize};
2
use std::fs;
3
use std::path::Path;
4

5
#[derive(Debug, Serialize, Deserialize, PartialEq)]
6
struct AppConfig {
7
    service_name: String,
8
    port: u16,
9
    log_level: String,
10
    features: Vec<String>,
11
}
12

13
#[derive(Debug)]
14
enum ConfigError {
15
    Io(std::io::Error),
16
    UnknownFormat(String),
17
    Parse(String),
18
}
19

20
impl std::fmt::Display for ConfigError {
21
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
22
        match self {
23
            ConfigError::Io(e) => write!(f, "io error: {e}"),
24
            ConfigError::UnknownFormat(ext) => write!(f, "unsupported config extension: .{ext}"),
25
            ConfigError::Parse(msg) => write!(f, "parse error: {msg}"),
26
        }
27
    }
28
}
29
impl std::error::Error for ConfigError {}
30
impl From<std::io::Error> for ConfigError {
31
    fn from(e: std::io::Error) -> Self {
32
        ConfigError::Io(e)
33
    }
34
}
35

36
/// Load a config file, choosing the parser from its extension.
37
fn load_config(path: &Path) -> Result<AppConfig, ConfigError> {
38
    let text = fs::read_to_string(path)?;
39
    let ext = path
40
        .extension()
41
        .and_then(|e| e.to_str())
42
        .unwrap_or("")
43
        .to_lowercase();
44

45
    match ext.as_str() {
46
        "json" => serde_json::from_str(&text).map_err(|e| ConfigError::Parse(e.to_string())),
47
        "toml" => toml::from_str(&text).map_err(|e| ConfigError::Parse(e.to_string())),
48
        "yaml" | "yml" => {
49
            serde_norway::from_str(&text).map_err(|e| ConfigError::Parse(e.to_string()))
50
        }
51
        other => Err(ConfigError::UnknownFormat(other.to_string())),
52
    }
53
}
54

55
fn main() -> Result<(), Box<dyn std::error::Error>> {
56
    let dir = std::env::temp_dir();
57
    let default = AppConfig {
58
        service_name: "billing".into(),
59
        port: 9000,
60
        log_level: "info".into(),
61
        features: vec!["metrics".into(), "tracing".into()],
62
    };
63

64
    // Write the SAME config in three formats from one struct.
65
    let json_path = dir.join("cfg.json");
66
    let toml_path = dir.join("cfg.toml");
67
    let yaml_path = dir.join("cfg.yaml");
68
    fs::write(&json_path, serde_json::to_string_pretty(&default)?)?;
69
    fs::write(&toml_path, toml::to_string(&default)?)?;
70
    fs::write(&yaml_path, serde_norway::to_string(&default)?)?;
71

72
    // Load each back -- all yield an identical, fully-typed AppConfig.
73
    for path in [&json_path, &toml_path, &yaml_path] {
74
        let loaded = load_config(path)?;
75
        println!(
76
            "{:<4} -> service={} port={} (matches default: {})",
77
            path.extension().unwrap().to_str().unwrap(),
78
            loaded.service_name,
79
            loaded.port,
80
            loaded == default
81
        );
82
    }
83

84
    // An unsupported extension is a clean typed error, not a panic.
85
    let bad = dir.join("cfg.ini");
86
    fs::write(&bad, "x=1")?;
87
    if let Err(e) = load_config(&bad) {
88
        println!("expected failure: {e}");
89
    }
90

91
    for p in [json_path, toml_path, yaml_path, bad] {
92
        fs::remove_file(p).ok();
93
    }
94
    Ok(())
95
}

Real output from cargo run:

1
json -> service=billing port=9000 (matches default: true)
2
toml -> service=billing port=9000 (matches default: true)
3
yaml -> service=billing port=9000 (matches default: true)
4
expected failure: unsupported config extension: .ini

One AppConfig type, three text formats, and a single load_config that dispatches on the extension. Each parser converts its own error into the unified ConfigError, so the ? operator in load_config flows file-I/O and parse failures through one channel — and an unknown extension produces a descriptive, typed error instead of a crash. The struct definition is the only schema; the format is just a detail at the edge.

Exercises

Exercise 1: One struct, five formats

Difficulty: Easy

Objective: Confirm a single type round-trips correctly through four formats.

Instructions: In a fresh project (cargo new, then add serde --features derive, serde_json, toml, serde_norway, and rmp-serde), define Point { x: i32, y: i32, label: String } deriving Serialize, Deserialize, Debug, and PartialEq. Serialize one Point to JSON, TOML, YAML, and MessagePack (use to_vec_named for MessagePack), deserialize each back, and assert! that all four parsed values equal the original.

1
use serde::{Deserialize, Serialize};
2

3
// TODO: derive Serialize, Deserialize, Debug, PartialEq
4
struct Point {
5
    x: i32,
6
    y: i32,
7
    label: String,
8
}
9

10
fn main() -> Result<(), Box<dyn std::error::Error>> {
11
    let p = Point { x: 3, y: -7, label: "origin-ish".into() };
12
    // TODO: round-trip through JSON, TOML, YAML, MessagePack and assert equality
13
    Ok(())
14
}

Solution

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize, PartialEq)]
4
struct Point {
5
    x: i32,
6
    y: i32,
7
    label: String,
8
}
9

10
fn main() -> Result<(), Box<dyn std::error::Error>> {
11
    let p = Point {
12
        x: 3,
13
        y: -7,
14
        label: "origin-ish".into(),
15
    };
16

17
    let from_json: Point = serde_json::from_str(&serde_json::to_string(&p)?)?;
18
    let from_toml: Point = toml::from_str(&toml::to_string(&p)?)?;
19
    let from_yaml: Point = serde_norway::from_str(&serde_norway::to_string(&p)?)?;
20
    let from_mp: Point = rmp_serde::from_slice(&rmp_serde::to_vec_named(&p)?)?;
21

22
    assert_eq!(from_json, p);
23
    assert_eq!(from_toml, p);
24
    assert_eq!(from_yaml, p);
25
    assert_eq!(from_mp, p);
26

27
    println!("all four formats round-tripped equal");
28
    Ok(())
29
}

Real output from cargo run:

1
all four formats round-tripped equal

The Box<dyn std::error::Error> return type lets the different error types from each format crate flow through the same ?. PartialEq is what makes the four assert_eq! calls compile and pass.

Exercise 2: Parse a TOML config with a nested table

Difficulty: Medium

Objective: Read a real-world-shaped TOML config that includes a [table] section, then re-serialize it.

Instructions: Define Server { host: String, port: u16 } and Settings { title: String, server: Server } (derive Serialize, Deserialize, Debug). Parse the TOML literal below into a Settings, print the host and port, then serialize it back to TOML and print the result. Observe how the nested struct becomes a [server] table.

1
use serde::{Deserialize, Serialize};
2

3
// TODO: define Server and Settings with the right derives
4

5
fn main() -> Result<(), Box<dyn std::error::Error>> {
6
    let toml_in = r#"
7
title = "prod"
8

9
[server]
10
host = "0.0.0.0"
11
port = 8080
12
"#;
13
    // TODO: parse into Settings, print host:port, re-serialize to TOML
14
    Ok(())
15
}

Solution

1
use serde::{Deserialize, Serialize};
2

3
#[derive(Debug, Serialize, Deserialize)]
4
struct Server {
5
    host: String,
6
    port: u16,
7
}
8

9
#[derive(Debug, Serialize, Deserialize)]
10
struct Settings {
11
    title: String,
12
    server: Server,
13
}
14

15
fn main() -> Result<(), Box<dyn std::error::Error>> {
16
    let toml_in = r#"
17
title = "prod"
18

19
[server]
20
host = "0.0.0.0"
21
port = 8080
22
"#;
23

24
    let settings: Settings = toml::from_str(toml_in)?;
25
    println!(
26
        "{} -> {}:{}",
27
        settings.title, settings.server.host, settings.server.port
28
    );
29

30
    let back = toml::to_string(&settings)?;
31
    println!("reserialized:\n{back}");
32
    Ok(())
33
}

Real output from cargo run:

1
prod -> 0.0.0.0:8080
2
reserialized:
3
title = "prod"
4

5
[server]
6
host = "0.0.0.0"
7
port = 8080

The nested Server struct maps to TOML’s [server] table both ways. Notice that the scalar title is emitted before the table — the toml crate orders output so that all top-level keys precede any tables, which is required by the TOML grammar.

Exercise 3: Summarize a CSV file

Difficulty: Medium

Objective: Deserialize CSV rows into typed records and compute a summary.

Instructions: Define Sale { product: String, units: u32, revenue: f64 } deriving Deserialize and Debug. Using csv::Reader::from_reader, deserialize the CSV string below into Sale records, then print the total revenue and the single product with the highest revenue. Each row deserializes into a fully-typed Sale — no manual string-to-number parsing.

1
use serde::Deserialize;
2

3
// TODO: define Sale with derive(Deserialize, Debug)
4

5
fn main() -> Result<(), Box<dyn std::error::Error>> {
6
    let csv_in = "\
7
product,units,revenue
8
widget,120,2400.0
9
gadget,80,3200.0
10
gizmo,45,900.0
11
";
12
    // TODO: deserialize rows, print total revenue and the top product
13
    Ok(())
14
}

Solution

1
use serde::Deserialize;
2

3
#[derive(Debug, Deserialize)]
4
struct Sale {
5
    product: String,
6
    units: u32,
7
    revenue: f64,
8
}
9

10
fn main() -> Result<(), Box<dyn std::error::Error>> {
11
    let csv_in = "\
12
product,units,revenue
13
widget,120,2400.0
14
gadget,80,3200.0
15
gizmo,45,900.0
16
";
17

18
    let mut rdr = csv::Reader::from_reader(csv_in.as_bytes());
19
    let mut total = 0.0;
20
    let mut best: Option<(String, f64)> = None;
21

22
    for record in rdr.deserialize() {
23
        let sale: Sale = record?;
24
        total += sale.revenue;
25
        if best.as_ref().map_or(true, |(_, r)| sale.revenue > *r) {
26
            best = Some((sale.product.clone(), sale.revenue));
27
        }
28
        let _ = sale.units; // available if you want a per-unit figure
29
    }
30

31
    let (top_product, top_revenue) = best.expect("at least one row");
32
    println!("total revenue = {total}");
33
    println!("top product = {top_product} ({top_revenue})");
34
    Ok(())
35
}

Real output from cargo run:

1
total revenue = 6500
2
top product = gadget (3200)

csv::Reader reads the header row to map columns to the Sale fields by name, and each record? yields a typed Sale with units already parsed as u32 and revenue as f64. The map_or(true, ...) keeps the first row as the initial “best” and then updates it whenever a higher-revenue row appears.

Beyond JSON: TOML, YAML, MessagePack, bincode, and CSV with Serde

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Key Differences

Common Pitfalls

Reaching for the deprecated serde_yaml

TOML’s top level must be a table

CSV cannot represent nested structs

MessagePack: compact (array) form drops field names

bincode: decode with the same config you encoded with

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: One struct, five formats

Exercise 2: Parse a TOML config with a nested table

Exercise 3: Summarize a CSV file

Reaching for the deprecated `serde_yaml`