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

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.

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

I see your argument tho maybe im just not getting the real use case.

Because when saying defaulting back to string and thatfor ignoring typing, wouldnt that just be the same as beeing typeless? Therefor doesn't every format support string therefor supporting typeless?

Also, in how many cases do you need to parse the same configuration in multiple different languages?

Im not saying its not useful - i just try to get the use case for this arguments.

So i get your point with date/time - while i may be an oldie with still preferring just having an integer seconds - but thats subjective to me.

Tho the quote for string argument i can't fully agree on. While sure in for example a json i would have to quote the values if i want them "typeless as string" - tho json is far supported everywhere and i'm able to interpret the parsed string values in whatever way i want to.

Adding a new dependency (confetti parsing) to spare out quotes doesn't seem to be worth the convenience to me.

Tho - both probably very subjective things to me.

Here's an actual case I ran into with JSON and it's bizarre number treatment:

Neo4j uses 128 bit ids. The JSON API retrieves these ids as strings of digits, Python library reading this JSON decided to interpret these as double precision floats. And sometimes it works, other times: not so much...

The whole selling point of configuration formats is to allow multiple languages to access the same data. So, cases when multiple languages have to read the same configuration format are exceedingly common.

The fact that the format supports other types means that someone (probably not you) will use those types, and then (probably you) will have to deal with the mess created by that person. I don't trust programmers in general to write good code... if possible to prevent them from writing bad code, then why not?

I think parsing the config in multiple target langs is definitely a counter-example where having a type system in the config lang can be useful as a lowest common denominator that you then conform all the parsers too

Well im working alot with json in my job and privat coding life used from all sorts of different languages, and so far i always could sort stuff out.

And well - if anyone trusts external coders he should be damned (or isnt he already for doing so? never trust external data - the golden rule...)

Your case is interesting, i worked with Neo4j years ago in a PHP project and never run into such issues, but maybe i was just lucky.

Nowadays i code mostly golang and im always making sure that whatever an external party sends me is what im expecting (validation ...).

To your point of preventing somebody to write bad code - i've given up on that. Whenever i thought the environment will enforce someone to write proper code, people proof me to be wrong be finding new ways to do the most absurd things.

But ye, its worth a try.

So - why i question such a thing? Because i'm not a fan of adding more and more 3'rd party dependencies to my projects. And while confetti might be a good thing (i never said it can't be) it wont get into any default packaging in a forseeable future meaning i have to make sure that the dependency stays stable which adds another task and liability on my end. So instead of having to deal with the devil i know (validating json data) i have to deal with a new one to eliminate the old one.

Time will tell if confetti will make its way into stable reliable state for common languages - than i might give it a try.