Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I made Confetti: a configuration language file format

confetti.hgs3.me

Post reply on HN
Print view View original

1–10 of 64 posts

Show HN: I made Confetti: a configuration language file format

#1

Post by hgs3 »

Hello everyone, I created Confetti: a simple, typeless, and localization-friendly configuration language designed for human-editable configuration files.

In my opinion, JSON works well for data interchange, but it's overused for configuration, it's not localization-friendly, and it's too syntactically noisy. INI is simple but lacks hierarchical structures and doesn't have a formal specification. Confetti is intended to bridge the gap.

I aim to keep Confetti simple and minimalistic, while encouraging others to extend it. Think of it like Markdown for configuration files: there's a core specification, but your welcome to create your own variations that suit your needs.

Show HN: I made Confetti: a configuration language file format
confetti.hgs3.me

Re: Show HN: I made Confetti: a configuration language file format

#7

Post by ablob »

voodooEntity wrote: post #6

Why is typeless considered something good?

I guess its because you can allow for custom data formats. You'll have to validate/parse the file anyways, and maybe having utc timestamps is worse than local date-time notation. Especially if the user is supposed to edit the file by hand.

I know for sure I'd like "timeout: 1h6m10s" more than "timeout: 3970". So unless you want to support really specific datatypes just being typeless is better. Putting everything in double quotes to get a string, while spec-wise would be typed, is not enough when the backing data type is not going to be a string. So you might as well throw it away and let the program handle all type conversion.

Re: Show HN: I made Confetti: a configuration language file format

#8

Post by anentropic »

voodooEntity wrote: post #6

Why is typeless considered something good?

You're going to read the configuration in a target programming language

So if the config format has its own type system you then have to convert between config types and language types

If the config type doesn't map exactly onto the target lang type you either ignore it and accept some values won't round-trip cleanly or without error, or you fall back to using strings (e.g. various possible integer type sizes, signed/unsigned etc, or decimal values via JSON)

Not saying it's always the right choice, but I can see why having lowest common denominator stringly-typed values as the config format can be seen as a feature allowing you to define the type system that the config will be parsed under to suit each particular application

Re: Show HN: I made Confetti: a configuration language file format

#9

Post by unwind »

Nice, I found one typo/editing thing though which kind of makes it contradict itself:

The first paragraph says:

[...] It is minimalistic, untyped, and opinionated. [...]

but then under "Notable features" it begins with a big bold *Unopinionated*, so that was very confusing.

Re: Show HN: I made Confetti: a configuration language file format

#10

Post by IshKebab »

> Confetti does not compete with JSON or XML, it competes with INI.

It clearly competes with JSON.

I think I would still much rather use JSON5 over this. It's quite similar in terms of structure and terseness, but I don't have to learn anything.

    // This is a comment.
    {
        probe_device: ["eth0", "eth1"],
        users: [
            {
                user: "*",
                login: "anonymous",
                password: "${ENV:ANONPASS}",
                machine: "167.89.14.1",
                proxy: {
                    try_ports: [582, 583, 584],
                },
            },
            {
                user: "Joe Williams",
                login: "joe",
                machine "167.89.14.1",
            },
        ],
    }
Still, it seems fairly well designed and elegant. Way better than YAML or TOML for example. Typeless seems like a bad decision in some ways but I can see the advantages.

Top marks on the name!

Post reply on HN