It's not really a solution though because you only notice you need to do it after it triggers a bug.

You need a format that doesn't let you make this mistake in the first place, like [everything except YAML].

Looked at the sibling comments. Has everybody collectively forgotten that XML exists? This stuff was solved decades ago, XSDs can check types.

TOML nesting is indeed a joke. YAML & JSON "look clean", but try to match up nesting in a large document without help from text editor highlights, then see how easy it is in XML.

XML has universal support everywhere, has first-class tooling for everything that's being re-invented in these other languages, but it's not "cool" any more.

Pkl (from Apple land) and Dhall (from Haskell land) both solve some of these pain points as well as some others, especially being more seamless about integrating schema with config.

Jsonnet, I haven't used personally but I know people who have raved about it.

Ones I know less about include KCL, CUE, and Nickel.

I like HOCON, although it's a bit obscure. It's a JSON syntax superset with the same data model, designed for human written config.

It doesn't have schema support however you arguably don't need one, because the software that reads the config specifies the type of keys when the value is read and casting takes place then. If the software expects a string, it reads the value as a string, if it expects a number it's parsed as a number and so on.

HOCON has hierarchical merging, include files, a more convenient syntax, ability to read environment variables, substitutions, comments and a few other convenience features. In Conveyor, a tool for packaging desktop apps I wrote that uses it, it's also extended so you have "hash-bang includes". Those are includes that specify a program to run instead of a file, the output is then included and parsed at that point. This lets you escape from declarative config to a fully dynamic computation if you need to. You can disable this feature with a command line flag if you don't trust the config you're parsing (and also env var substitution).

You can also render the whole config to regular JSON if you need to.

I find that set of features to nicely balance config complexity with read/writeability. The main issue is that the main library is not well maintained, and the best implementation is for the JVM. You could give it a C API these days with Native Image but nobody has.

Main downside vs yaml is that IDEs and editors can use YAML schemas to give auto-completion whereas they don't do that for HOCON.

JSONC. https://onury.io/jsonc/

It can be hard to find an implementation of this if you're working in a not-so-popular language (looking at you Swift) but JSONC has had the best developer experience of anything I've tried so far.

It's basically JSON with single and multi line comments and trailing commas.

Json5 is fine. Of the boring config options, it's the best.

The better alternative to yaml are json (particularly json with comments), properties files and xml files.

Basically any mainstream configuration syntax.

The really big problem with xml wasn't actually the verbosity of xml itself but the fact that it was popular in a time before rails popularized "convention over configuration"'

https://rcl-lang.org/

Protobuf/thrift?

My last big enterprise job, we did a lot of YAML templating and of course ran into issues like this all the time, eventually though we solved it by requiring defined schemas for all configs and validating those schemas in our pipeline. More overhead but that validation also caught lots of issues aside from the YAML gotchas, it was a decent setup to work with in the end.

The trailing comma thing gets me nearly every time I edit a json config file.

I don't think json supports comments, which makes it a non-starter for a lot of folks.

JSON but with the structure of YAML, would be nearly perfect to me. JSON was not designed for humans to read and write directly, it happens to be easy enough that it's quite common but it's not exactly a nice experience. Take that base and remove the need to quote key values, enforce indentation for clear structure and to remove the need for braces and commas (the no trailing commas rule in JSON kills me too), and support the markdown-like list syntax alternative and I think really that's all most people want out of YAML anyways. I don't understand or ever want to work with their references or variables or whatever the hell they add, any of that is much better off in code than in config as far as I'm concerned.

The following code will only validate when gameServerVersion is a hex string between 9 and 32 characters:

  #!/usr/bin/env python
  import sys
  import re
  from typing import Annotated
  from pydantic import BaseModel, AfterValidator, validator
  from pydantic_yaml import parse_yaml_raw_as
  
  
  def validate_commit_id(s: str) -> str:
    assert re.search(r"^[0-9a-f]{9,32}$", s), f"{s} is not a commit id"
    return s
  
  
  CommitId = Annotated[str, AfterValidator(validate_commit_id)]
  
  
  class Model(BaseModel):
    gameServerVersion: CommitId
  
  
  def main():
    text = sys.stdin.read()
    conf = parse_yaml_raw_as(Model, text)
    print(conf)
  
  
  if __name__ == "__main__":
    main()
    

  $ cat conf.yaml
  gameServerVersion: 556474e378
  $ python parse.py < conf.yaml
  pydantic_core._pydantic_core.ValidationError: 1 validation error for Model
  gameServerVersion
    Input should be a valid string [type=string_type, input_value=inf, input_type=float]
  
  $ cat conf.yaml
  gameServerVersion: "556474e378"
  $ python parse.py < conf.yaml
  gameServerVersion='556474e378'
  
  $ cat conf.yaml
  gameServerVersion: "Infinity"
  $ python parse.py < conf.yaml
  pydantic_core._pydantic_core.ValidationError: 1 validation error for Model
  gameServerVersion
    Assertion failed, Infinity is not a commit id [type=assertion_error, input_value='Infinity', input_type=str]

Not technically, but pratically yes. The chance of having a single letter "e" and everything else a number would be very rare for a full SHA1 hash. I'm not interested in doing the calculations but if anyone wants to do it, it sounds like a cool math problem to solve

Technically no, but realistically yes.

Actually, yes. We use yamerl parser for parsing YAML in Erlang and Erlang has both strings and atoms; yamerl generally turns unquoted YAML strings into atoms and double-quoted YAML strings into strings.

But nobody else cares about how yamerl parses YAML for Erlang and lots of tool try to re-normalize YAML as they process it; so if we put e.g.

    config:
        option: "this_must_be_a_string"

    config:
        option: this_must_be_a_string

Heh, maybe I missed the joke too. Thing is all of the problems people generally think of with YAML strings are solved with just one set of quotes so I don't quite get it either way. Maybe this would have some effect on strings that themselves contain quotes? But that's a special case in every single language with quoted strings, not a YAML problem.

Not a gamer so first time I heard this. For some reason it bothers me so much. It's not random, it's perfectly reproducible and has a crystal clear explanation. They are using short hashes for version numbers which is looking for problems in the first place.

Sloppy technical writing.

Or clickbait since the title sounds more interesting than “oh YAML is dumb”.

> I suspect that the OP may be confused about how git hashes are computed.

I don't think they are. The use of "RNG" is referring to how a "random" commit sha lead to this bug. Commit SHAs are, for all intents and purposes, random.

You could test this against thousands of SHAs and never encounter one that meets the criteria to trigger the bug.