I like toml files. https://github.com/toml-lang/toml
In Systemd/systemd – shared: add minimal JSON tokenizertoml-lang
toml
OPEN SOURCE2013–2026
toml-lang / toml
toml
Tom's Obvious, Minimal Language
93Distinct people
105Mentions
2Explicit recommenders
20.7KGitHub stars
What to know before exploring
What it is
Tom's Obvious, Minimal Language
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I recommend taking a look at TOML [1] as an alternative to YAML for many situations. Objectives: TOML aims to be a minimal configuration file format that's easy to read due to…
xpe used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year105 dated mentions
Observed mentions: 2013-02-24 03:22:38 UTC to 2026-03-31 07:31:48 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 15 | 3 | 12 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 14 | 2 | 12 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 3 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
TOML
Tom's Obvious, Minimal Language.
By Tom Preston-Werner, Pradyun Gedam, et al.
This repository contains the in-development version of the TOML specification.
You can find the released versions at https://toml.io.
Objectives
TOML aims to be a minimal configuration file format that's easy to read due to
obvious semantics. TOML is designed to map unambiguously to a hash table. TOML
should be easy to parse into data structures in a wide variety of languages.
Example
# This is a TOML document.
title = "TOML Example"
[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00 # First class dates
[database]
server = "192.168.1.1"
ports = [ 8000, 8001, 8002 ]
connection_max = 5000
enabled = true
[servers]
# Indentation (tabs and/or spaces) is allowed but not required
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
[clients]
data = [ ["gamma", "delta"], [1, 2] ]
# Line breaks are OK when inside arrays
hosts = [
"alpha",
"omega"
]
Comparison with Other Formats
TOML shares traits with other file formats used for application configuration
and data serialization, such as YAML and JSON. TOML and JSON both are simple and
use ubiquitous data types, making them easy to code for or parse with machines.
TOML and YAML both emphasize human readability features, like comments that make
it easier to understand the purpose of a given line. TOML differs in combining
these, allowing comments (unlike JSON) but preserving simplicity (unlike YAML).
Because TOML is explicitly intended as a configuration file format, parsing it
is easy, but it is not intended for serializing arbitrary data structures. TOML
always has a hash table at the top level of the file, which can easily have data
nested inside its keys, but it doesn't permit top-level arrays or floats, so it
cannot directly serialize some data. There is also no standard identifying the
start or end of a TOML file, which can complicate sending it through a stream.
These details must be negotiated on the application layer.
INI files are frequently compared to TOML for their similarities in syntax and
use as configuration files. However, there is no standardized format for INI and
they do not gracefully handle more than one or two levels of nesting.
Further reading:
YAML spec: https://yaml.org/spec/1.2/spec.html
JSON spec: https://tools.ietf.org/html/rfc8259
Wikipedia on INI files: https://en.wikipedia.org/wiki/INI_file
Get Involved
Documentation, bug reports, pull requests, and all other contributions are
welcome!
Wiki
We have an Official TOML Wiki that
catalogs the following:
Projects using TOML
Implementations
Validators
Language-agnostic test suite for TOML decoders and encoders
Editor support
Encoders
Converters
Please take a look if you'd like to view or add to that list. Thanks for being a
part of the TOML community!
Read the full README on GitHubWhat Hacker News says
14 sourcesTom's Obvious, Minimal Language
2 points · Open discussionJSON is okay, but I hope TOML will gain traction soon. Because comments. And trailing commas. Rust Crate is already using TOML for package metadata.
https://github.com/toml-lang/toml
http://doc.crates.io/manifest.html
In CoreOS is building a container runtime, RocketLink for the lazy https://github.com/toml-lang/toml
In FreeBSD: the next 10 yearsI see many mentions of YAML in the comments, but why not TOML? (https://github.com/toml-lang/toml)
In Hjson, the Human JSONFirst of all, congrats on releasing.
Now let me be sceptical for the following reasons:
1. I don't believe the world needs another human-rwable object notation format. We have json for read-only object notation and both YAML and TOML (https://github.com/toml-lang/toml) for human-writable stuff, config files etc. These formats are strongest when they are widespread and people don't need six different parsers to deal with six different services.
2. "ludicrous compactness" seems at odd with the concept of things being human readable. If you need to save on space, you're probably better off with a binary (protobuf-like) format.
3. What you're doing here seems to be a slightly less verbose take on YAML. I don't see the point here.
In Show HN: LCON 1.0 – For reals this time (Ludicrously Compact Object Notation)Not only that, but TOML is still considered unstable by its author. Granted, it hasn't been updated in several months. But that seems like a shaky foundation to be building on top of.
From: https://github.com/toml-lang/toml
"Latest tagged version: v0.2.0.
Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly."
In Cargo, Rust's Package ManagerHow about TOML? There was an implementation for most languages under the sun within a week of its release.[1]
(Certainly I acknowledge that it is not as ubiquitous as JSON or YAML, but I do like TOML better than both of those for configuration.)
[1] - https://github.com/mojombo/toml#implementations
In JSON5 is a proposed extension to JSONProblem is people don't agree on Good Parts. People seem to think keeping YAML a superset of JSON is the good part. I'd think otherwise.
Anyway, http://ogdl.org/ is one candidate for YTGP (YAML The good parts) but it's comments can carry metadata, which is a huge turn-off, others think TOML (https://github.com/mojombo/toml) is a good replacement, but it has no support for alternate number types. You write in something like
mask = 0xDEADBEEF
into something like
mask = 3735928559
In JSON5 is a proposed extension to JSONWe tried to use YAML at first, but problems with data types (can't correctly remember what, but there was no way to force something to be something) made us to rewrite our test fixtures to JSON. The only problem with JSON for us is that it doesn't support any comments, but JSON5 seems to fix it.
There's a interesting format for configuration called TOML[1], you should check it out!
[1] https://github.com/mojombo/toml
In JSON5 is a proposed extension to JSONI honestly thought TOML (https://github.com/mojombo/toml - created by founder of Github) was a good configuration format. But unfortunately, I'm not sure that Tom has been a good steward of it and most of the interest in the early dies died off because Github issues would go unanswered or unresolved for months.
In JSON5 is a proposed extension to JSONI see this comment every time for many of years in almost every discussion about using JSON for configuration and while YAML is certainly used by many projects most of the people still continue to use JSON and I think that's because YAML sometimes feels like Scala of serialization markups when people just want something like Python. I personally think that TOML[0] is not only more simple but also as easy to read as YAML and we use it in our projects without any issues.
0. https://github.com/mojombo/toml
In JSON5 is a proposed extension to JSON> I hope they won't use this awkward "double-escaped backward-slashes in reglular expressions"
Yes, they will[0]. YAML is definitely better, but I believe they have a strong opinion against YAML[1].
[0]: https://github.com/atom/language-toml/blob/master/grammars/t...
[1]: https://github.com/mojombo/toml
In GitHub's new text editor leaked on Twitter