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}
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.
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 nightly-export
:schedule "0 3 * * *"
:retry (backoff :max 5))
2. These are schema and app concerns. Schema is something I plan to tackle.
Discriminators are one of the fundamental building blocks of composition (sum types in ADT parlance). The workarounds for expressing them are verbose, ugly, and complicate schemas.
Consider `shape: circle: { radius : 1}` vs the workarounds like `shape: { type: circle, radius: 1}` or `shape: { circle: { radius: 1 }`.
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
They look like a human to me.
I believe you, but it's hard to tell when prose reads like something Claude generated.
LLMs make it so easy to blurt out hundreds of thousands of LOC with no effort. Too much to assess critically. So I've formed new heuristics for judging whether a project is worth my attention. One of those is LLM-flavoured prose, which I have come to view as a signal of low effort.
[0]: https://github.com/soml-lang/soml/blob/main/comparison.md
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.
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/).
> 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.
TOML needs quotes too. But if you forget them, TOML nests silently, while SOML errors.
I have updated the readme to make these things more clear.
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. A GUI can also ensure that there are no invalid settings that are discovered separately from the edit session (sure it may not do so, but it has the possibility unlike whatever random text editor the user opens the config in).
> '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'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.
Trying to remove a required number the last remaining digit is highlighted so that you can type over it.
You've already failed. Config files are for more than just editing in an environment that you solely control.
But they added syntax, such as unit specifiers for time.
And some syntax, like YAML bare strings, or XML entities referring to external resources, has to be removed.
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.
> A value's type comes from its syntax, never from its content […] allowed-origins: [ 'https://example.com' 'https://example.org' ]
This looks like URLs, but are strings. What if you had:
> allowed-origins: [ 'httpș://example.com' 'ħttps://example.org' ]
Still strings and therefore fine for the SOML parser, but probably not a valid configuration in terms of the application-level types of the values. The syntax telling you the types is of limited utility as soon as the application schema has more specific ideas about the types than the configuration language.
"exactly as written" was wrong for the value. Only the type is. The spec already says a float is IEEE 754 binary64, same as JSON. Fixed the readme.
> Still strings and therefore fine for the SOML parser,
I have plans for some kind of schema support.
Pet peeve of mine, but I would argue that it's better to always keep units baked into the key.
If you have:
timeout_s: 30
If you have:
timeout: 30s
- Target language doesn't have duration types (looking at the list - Ruby?)
- If you ever need to convert to/from a data format without durations like JSON
So basically you have to use SOML across your entire stack and always use languages that have native duration types, and also you have to be careful never to convert SOML to/from JSON (which is highly likely if you ever have to interface with external APIs). Do any of those things and you'll likely run into a unit confusion scenario at some point.
But there are going to be lots of configs that won't have native type like size. Again, just include units in key:
max_size_bytes: 30000000
Ruby:
config = SOML.load_file('config.soml', symbolize_names: true)
config[:timeout] # what are the units? uses SOML::Duration non-Ruby type
1. You should mention TOML in your first paragraph. "Why not TOML" exists at the end
2. how often are "instants"/dates really specified? Are you baking this in for TOML parity?
If you want leaner, drop this. If nothing else it's a lot of grammar.
If you want to lean in to "A value's type comes from its syntax", I'd suggest taking a cue from postgres and JS -- extensible literals. With JS tagged literals it would look like date`2026-09-19T14:00:00Z`. Conforming readers can fall back.
I'd use ver`3.1.0` 1000x more in config files than dates... I do like durations being baked in though.
Solid improvements over TOML and YAML.
The reason for not having is simply a matter of specification size. ISO-8601 is full of weirdness! SOML's date spec is reasonable looking but there is still a lot of nuance.
Having durations is nice and instants are highly complementary. My feedback is just that if lots of literal formats are desired, maybe an extensible literal format!
It's already powering the frontmatter of my website: https://github.com/sindresorhus/sindresorhus.github.com/blob...
To me being able to do some templating/inheritance to generate slightly different config (or deviating from the standard/default config) seems to be vital as a config DSL. In that regard, even YAML is superior with its half-ass anchor thingy.
Also the glaring: Error in user YAML: (<unknown>): did not find expected ',' or '}' while parsing a flow mapping at line 10 column 10