138
TOML (lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
[-] Ephera@lemmy.ml 38 points 2 days ago* (last edited 2 days ago)

Counterpoints:

  • TOML is intended for configuration, not for data serialization, so you shouldn't be sending it over the wire in all too crazy ways anyways.
  • Most protocols will have a built-in way of knowing when the whole content has been transferred, typically by putting a content length into the header.
  • Having to wait until the closing } or ] can also be a disadvantage of JSON, since you cannot stream it, i.e. start processing the fields/elements before the whole thing has arrived. (You probably still don't want to use TOML for that, though. JSONL, CSV or such are a better idea.)
[-] CreamyJalapenoSauce@piefed.social 3 points 1 day ago* (last edited 1 day ago)

I'm only being pedantic. Toml is not bad. Yaml I personally don't like because I don't approve of semantically required whitespace but I know I'm in the minority there.

  • It's not the norm in smaller companies, but big companies can use config servers where an app will retrieve its config on startup over the network. To be fair, I think they fall back to a platform specific encoding though.
  • Better hope it's built in. I don't remember the last time I verified a Content-Length was accurate. Also this generally applies to networking; disk writes don't get this same verification especially if a process is killed mid-write.
  • True point, no real notes. I've recently been dealing with streaming JSON for AI, it's SOO verbose for the few tokens that come across in each message. I don't know how gRPC wasn't chosen, or at least made an option, but oh well.

You make good, valid points and I know I'm talking about edge cases that require the stars to align to break. It reminds me of an old, not-quite-relevant-but-oh-well saying "a 'one in a million' chance at 1GHz happens every millisecond." The law of large numbers isn't always on our side.

[-] Decq@lemmy.world 2 points 10 hours ago

Whitespace being part of semantics is always a bad design decision. You're not alone in this. I wish this was more widely accepted. But alas, it's not. For a configuration language I can accept it a bit more. But for a programming language it's a big faux pas in my opinion (looking at you python).

[-] crater2150@feddit.org 1 points 1 hour ago

I was in the same camp when I had to use Python on the job, but when Scala introduced (optional) significant whitespace, I actually grew to like it a lot. I think the important difference to Python is, that with a good type system and compile time checks a whitespace error is basically always a compile time error in Scala. That's also for me it's worse in a configuration language (unless you have a schema file for validation, which is rarely the case sadly)

this post was submitted on 24 Feb 2026
138 points (100.0% liked)

Programmer Humor

41153 readers
38 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 6 years ago
MODERATORS