? Curious Hacker Newsfront | about | view on HN unofficial mirror
SOML – A Config Format for Humans (github.com)
23 points by microflash 2026-11-02 | 9 comments | side by side | 1 rewritten | show 1 removed | updated 20:05 UTC
 help



From the title, I thought this was a specification for configuring humans. I don't quite know what that means, and I'm disappointed still not to know.

From the title, I thought this was a specification for configuring humans. I don't quite know what that means, and I'm disappointed still not to know.

A joke about how the title reads, with nothing about the config format itself.

reply

spry_rook30 2026-11-02 19:43 | rewritten3/10snarkcurmudgeonly | original | prev | next [–]

The README reads as if it were LLM-generated, which seems at odds with a format pitched as "for humans." I'd rather hear from the author directly why the project matters than read a model's interpretation of it.

original comment by lightandlight

Ironically the project seems LLM-generated.

I don't want to read Claude's interpretation of why your project matters. I want you to tell me directly.

There's a real point about the README feeling LLM-written and wanting the author's own case for the project, so I dropped the ironic jab and kept the criticism.

reply

CodesInChaos 2026-11-02 19:248/10insightfulinformative | prev | next [–]

What I'm missing:

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.

What I'm missing:

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.

Gives specific, constructive technical feedback on number semantics and modeling tagged unions in the format.

reply


[flagged]

Looks like Windows *.ini format except ":" instead of "="...

Looks like Windows *.ini format except ":" instead of "="...

A short but real comparison to the INI format; it's a fair observation, not snark.

reply


Not really. INI has a fixed structure (section>key>value) and its values are untyped.

Not really. INI has a fixed structure (section>key>value) and its values are untyped.

A brief correction that points out real structural and typing differences from INI.

reply


So a stripped down variant of cue? Why not use cue directly?

So a stripped down variant of cue? Why not use cue directly?

A short but genuine question comparing SOML to CUE, an existing config language.

reply

brianm 2026-11-02 19:337/10informativeinsightful | parent [–]

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.

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.

A substantive answer: it points out that Cue's ecosystem only really works in Go, it's heavy on dependencies, and it fits a different role from an in-app config format.

reply


[flagged]

Can you add README sections for the schema and supported types?

Can you add README sections for the schema and supported types?

A genuine, constructive request for documentation on schemas and supported types.

reply


> Top-level arrays. A TOML file is always a table, so a list of records needs a wrapper key.

I'm curious for example configs that are top-level lists?

> Top-level arrays. A TOML file is always a table, so a list of records needs a wrapper key.

I'm curious for example configs that are top-level lists?

A real question asking for practical examples behind one of the format's claimed advantages.

reply


See also: HUML [1]

1: https://huml.io/

See also: HUML [1]

1: https://huml.io/

Points to a related config format, which helps readers compare the two.

reply




About | This page on Hacker News | HN Guidelines | Data: HN API

Curious Hacker News is an unofficial, experimental mirror and is not affiliated with, endorsed by, or operated by Hacker News or Y Combinator. Original comments are by their authors on news.ycombinator.com; rewritten text is AI-generated and was not written by the commenter.