Really? I feel the opposite. I’d much rather have indentation enforced by the language than merely convention.

Well, I don’t have a problem with incorrect indentation. As in, the people I work with indent their code correctly, so I don’t need enforcement. If you do need enforcement, you can also throw an autoformatter onto a braced language and it’ll be able figure it out.

But yeah, to me it’s rather that the additional visual cue of indentation + braces helps me a lot. I check the scope of things quite often. If I need to guestimate whether one line has a different indentation than another, that just takes longer and I’ll misread it more often.

But well, in that vein, I also like braces, because I like to use explicit scopes. If I construct a more complex variable which needs intermediate variables, then I’ll isolate the construction process into a separate scope, so that folks reading the code know for certain that these variables will not be used further down. It’s kind of like the isolation of a function, except you don’t explicitly pass things in.

The quotes thing is acceptable IMO since it allows for flexibility in keys (e.g. you can have a URL as a key)

For serializing data, absolutely. But no one in their right mind would use a URL for the name of a configuration field. 🙃

And I can kind of understand them disallowing comments, ever since I saw an XML file which had data encoded into comments. Not any XML file, but one of the most important XML formats in a larger company. Which, I guess, is why they were scared of adding more nodes, in case any applications wouldn’t be able to handle that.
But yeah, that is again assuming JSON to be used for serializing data, not for configuration. The two use-case are just kind of at odds.

I don’t think it has anything to do with error messages though, plenty of languages do that well without it.

Well, I don’t think it’s impossible to solve it without semicolons, but I do think that it makes it harder. And if it’s harder, it will be solved later, which can result in a culture of people not caring for readable errors. And that is then really hard to undo.

Rust has very few symbols, especially compared to pre-1.0 when they had ~ (box?) and @ (GC?).

Symbols in modern Rust are pretty reasonable IMO, but maybe that’s just stockholm syndrome.

Gross

The only gross thing I see is your indentation. I find the TOML to be more readable honestly.

In a config format, you want to group top level fields together, and it enforces that. Your example could be like this instead:

lintDebug:
  stage: build
  script:
    - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
  artifacts:
    paths:
      - app/lint/reports/lint-results-debug.html
    expose_as: "lint-report"
    when: always
  interruptible: true

It’s easy to tack stuff on like that, and it’s also easy to miss when quickly scanning, especially if you’re using 2-space indenting.

The TOML would be the same in either case, because it forces related fields to be grouped separately from child groups.

The main thing I don’t like about TOML is yellow table groups:

[[thing]] 

[[thing]] 

I rarely see it in the wild though.

IMO JSON5 is the best:

It’s trying to do two things at once, and ends up doing neither very well. The extra curly braces are there because it’s trying to be a data format, and it’s bad as a data format because it’s not universal. We’ve standardized on JSON as a community for data, and that’s unlikely to change, so we shouldn’t try to “fix” it just for configs. IMO, either use JSON or a config-specific format.

I agree that YAML is plain awful. It shouldn’t exist.

XML is awful for anything outside of markup, and even then I think we can do better. I’m partial to Lua tables:

    {x=10, y=45, "one", "two", "three"}

A typical HTML drop down menu {pulled from MDN):

<select name="pets" id="pet-select">
  <option value="">--Please choose an option--</option>
  <option value="hamster">Hamster</option>
  <option value="parrot">Parrot</option>
</select>

Could be like this in a Lua table:

{
  node="select", 
  name="pets", 
  id="pet-select", 
  {value="", "--Please choose an option--"}, 
  {value="hamster", "Hamster"}, 
  {value="parrot", "Pattot"}, 
} 

Or maybe something a little different with the node type outside:

select{
  name="pets", 
  id="pet-select", 
  option{value="", "--Please choose an option--"}, 
  option{value="hamster", "Hamster"}, 
  option{value="parrot", "Parrot"}, 
} 

I think QT Quick uses something like that, but it’s been years since I played with it.