> what you see is what you get: […] '10.20' and 10.20 are a string and a float, exactly as written.
This seems both underspecified and incorrect. Assuming a single-precision binary IEEE 754 floating-point number, 10.20 is actually 10.19999980926513671875. With double precision, it would be 10.199999999999999289457264239899814128875732421875. So what you see is not what you get, and it’s also unclear what exactly you’ll get.
> durations like 30s are real values, so nobody has to guess the unit of timeout: 30
I would argue that it's better to always keep units baked into the key.
If you have:
timeout_s: 30
Then unit information will never be lost, because the unit is always marshalled as a part of the key name and you don't have to worry if the target language has a duration type or not.
If you have:
timeout: 30s
Then unit information probably won't be lost, but could in the following scenarios:
- Target language doesn't have duration types (looking at the list - Ruby?)
- If you ever need to convert to/from JSON
So basically you have to use SOML across your entire stack and always use languages that have duration, and also never have to serialize to/from JSON (which also seems unlikely if you have to interface with external APIs).
Go into more specialized software domains like radiology and you simply can't include units as a part of the value:
Gotta be honest, any time there's a solution like there that makes it more "human" they've just removed the structure / syntax.
I'm guessing so you don't need to learn them, so then anyone off the street can edit the files, but it will break so bad without those guardrails, usually in some non-obvious way.
Leading us back to inventing some new "human" thing, but with more implicit rules, and the cycle continues.
> 'the name': 'quotes are the escape hatch, when a key needs spaces'
To quote David Fincher:
> They know you have computers and can show a Tyrannosaurus Rex eat a car, so they know you can do anything. The question is: what don't you do, not what do you do.
Constraints liberate; I wish people tended to more strictness. I had plenty of stumbling over "features", asking myself who couldve ever needed them. This particular one also irked me about CUE.
From the comments here I can infer that it has a schema and in turn I can extrapolate that this is as much "for humans" as many other config formats that are deterministically parseable.
A GUI is a config format for humans as it can you show what all of the configuration options are along with text that tells you what they do.
1. The readme doesn't make it clear what its "float" type is. A double, a decimal, implementation defined. I'm generally not a fan of restricting numbers to what a double can represent, like toml does.
2. It doesn't have a good way to model key-value pair like types such as tagged unions, polymorphic types, or function invocations. Simply allowing a key-value pair as a value (right associative) where the key is a string matching the keys of an object would fix this. Alternatively a function call syntax would fix this, which would also enable tuples as a concept distinct from arrays.
The tagged-union / function-call point is where I keep ending up too. Once a config needs “one of these shapes” or “this thing with these arguments”, data formats grow conventions on top (type: keys, YAML !tags, $ref), and every consumer reimplements them.
I’ve been building Forma (https://forma-lang.com), a small typed Lisp aimed at that zone. Everything is (head args...), so a tagged value and a call are the same syntax, and you declare the vocabulary yourself:
job and backoff are forms you define with typed holes. The checker reports errors at the line you wrote, even after macro expansion. The output is plain JSON (or generated Effect TypeScript, but could target any language), so the app reading it doesn’t embed the language.
It would be great if you had a simple website that allowed you to enter SOML and see the JSON side-by-side (similar to typescript playground https://www.typescriptlang.org/play/).
I think where TOML shines is when your configuration schema is relatively flat and simple. If you want to heavily nest configuration it can quickly get difficult to read. I’d love a more limited version of TOML that restricts the nesting depth.
Cue only really exists in go, and has a dependency chain to make maven weep.
I think cue is better thought of as a language you use to generate JSON (or yaml, or, let's be honest, k8s flavored yaml) configs rather than a config language you use in your app.
This seems both underspecified and incorrect. Assuming a single-precision binary IEEE 754 floating-point number, 10.20 is actually 10.19999980926513671875. With double precision, it would be 10.199999999999999289457264239899814128875732421875. So what you see is not what you get, and it’s also unclear what exactly you’ll get.
I would argue that it's better to always keep units baked into the key.
If you have:
Then unit information will never be lost, because the unit is always marshalled as a part of the key name and you don't have to worry if the target language has a duration type or not.If you have:
Then unit information probably won't be lost, but could in the following scenarios:- Target language doesn't have duration types (looking at the list - Ruby?)
- If you ever need to convert to/from JSON
So basically you have to use SOML across your entire stack and always use languages that have duration, and also never have to serialize to/from JSON (which also seems unlikely if you have to interface with external APIs).
Go into more specialized software domains like radiology and you simply can't include units as a part of the value:
I'm guessing so you don't need to learn them, so then anyone off the street can edit the files, but it will break so bad without those guardrails, usually in some non-obvious way.
Leading us back to inventing some new "human" thing, but with more implicit rules, and the cycle continues.
> 'the name': 'quotes are the escape hatch, when a key needs spaces'
To quote David Fincher:
> They know you have computers and can show a Tyrannosaurus Rex eat a car, so they know you can do anything. The question is: what don't you do, not what do you do.
Constraints liberate; I wish people tended to more strictness. I had plenty of stumbling over "features", asking myself who couldve ever needed them. This particular one also irked me about CUE.
But that's just a nit.
I don't want to read Claude's interpretation of why your project matters. I want you to tell me directly.
there's a very good chance there's no human involvement at all in this
A GUI is a config format for humans as it can you show what all of the configuration options are along with text that tells you what they do.
> CVE-2026-44244 injected a [core] section into .git/config for code execution.
Git config is not TOML. It’s an ini-based bespoke syntax
> SOML needs quotes for a literal dot.
So does TOML, the dot notation is for nested keys. You use quotes for a literal dot.
——
FWIW I like the decision to have a first class duration type.
1. The readme doesn't make it clear what its "float" type is. A double, a decimal, implementation defined. I'm generally not a fan of restricting numbers to what a double can represent, like toml does.
2. It doesn't have a good way to model key-value pair like types such as tagged unions, polymorphic types, or function invocations. Simply allowing a key-value pair as a value (right associative) where the key is a string matching the keys of an object would fix this. Alternatively a function call syntax would fix this, which would also enable tuples as a concept distinct from arrays.
I’ve been building Forma (https://forma-lang.com), a small typed Lisp aimed at that zone. Everything is (head args...), so a tagged value and a call are the same syntax, and you declare the vocabulary yourself:
job and backoff are forms you define with typed holes. The checker reports errors at the line you wrote, even after macro expansion. The output is plain JSON (or generated Effect TypeScript, but could target any language), so the app reading it doesn’t embed the language.It would be great if you had a simple website that allowed you to enter SOML and see the JSON side-by-side (similar to typescript playground https://www.typescriptlang.org/play/).
I think where TOML shines is when your configuration schema is relatively flat and simple. If you want to heavily nest configuration it can quickly get difficult to read. I’d love a more limited version of TOML that restricts the nesting depth.
[0]: https://github.com/soml-lang/soml/blob/main/comparison.md
I think cue is better thought of as a language you use to generate JSON (or yaml, or, let's be honest, k8s flavored yaml) configs rather than a config language you use in your app.
[0]: https://github.com/soml-lang/soml/blob/main/schema.md
I'm curious for example configs that are top-level lists?
Or it could be a list of records:
{name: 'Alice', age: 42}
{name: 'Bob': age: 44}
1: https://huml.io/