search

ghuntley / noyaml

A silly emotional rant about the state of devops tooling/the infrastructure sector in 2018. #noyaml.com
https://noyaml.com
GNU Affero General Public License v3.0
422 stars 29 forks source link

Suggest some alternatives #2

Open matthias-t opened 6 years ago

matthias-t commented 6 years ago

After all that, I still don't know how to replace YAML. Using structs et al. is not always possible. For example, when building a CLI, it may make sense to handle configuration by having a single YAML file open in vim instead of having a complex system of nested configuration subcommands.

Would it make sense to add a section with some alternatives to YAML (and how they are better)?

ghuntley commented 6 years ago

Indeed it would. Send in a PR!

matthias-t commented 6 years ago

As I said, I'm not really aware of any (except maybe TOML).

andreujuanc commented 5 years ago

Maybe code. Just simple code. Anything would do. C#, go, Ts, etc

ghuntley commented 5 years ago

Send in a PR!

rugk commented 5 years ago

…TOML :smile: :+1: (not used though)

matthias-t commented 5 years ago

The problem is that the different articles linked criticise different things.

Serialization

Serialization languages are overused, and code is great! But sometimes, serialization is necessary. How else should machines exchange structured data? How else should (e.g. system or application) configuration be handled? Would you write your system configuration in code? Personally, I prefer a serialization or configuration language. (For the latter category, see Nix for example.)

The YAML spec

It's bad, I guess. There are oddities and ambiguities. There also was no test suite for a long time, parsers have bugs. But most importantly, type inference (cf. Norway problem) and syntax typing in configuration sucks: the application should know which type it wants.

All these problems are solved by StrictYAML. But for now, it's only a parser, and while it's differences with YAML are very well documented and justified, there is no standalone specification. If you want things to change I'd recommend you help out over there. Criticising a spec is easy but writing a better one...

YAML

And I disagree — apart from its obscure spec and quirks, YAML is great. I use TOML (because of cargo) to and i find YAML document a lot easier to understand visually than TOML. It's structured data, and YAML makes this structure apparent. Data with a bit of nesting is unreadeable in TOML. There are many ways to write the same thing in TOML (e.g with nested.fields or [headers]). This leaves place for poor and inconsistent configuration style. The array of tables syntax is completely inconsistent [[with]] the rest of TOML and [[with]] the human mind.

Nobody wants to write YAML

Not true: I want to write YAML (but strict, please), whenever a human-friendly serialization language is appropriate. And not symbol-heavy JSON or alien TOML.

ghuntley commented 5 years ago

Please understand as it is now, this website is an art project about devops, an emotional rant about kubernetes, devops and yaml. I'm open to the idea of turning this website into a proper rational reference website related to serialization and configuration to resolve problems raised in https://github.com/ghuntley/noyaml/issues/2#issuecomment-499634789.

Have added the section for now.

image

matthias-t commented 5 years ago

cool, thanks!

matthias-t commented 5 years ago

As a reaction to the less-disciplined types of romantic poetry and what they considered the excessive sentimentality and undue social and political activism of Romantic works, the Parnassians strove for exact and faultless workmanship, selecting exotic and (neo-)classical subjects that they treated with rigidity of form and emotional detachment.

https://en.wikipedia.org/wiki/Parnassianism

brandonkal commented 4 years ago

ArchieML looks nice. It's a bit like a mix between YAML and TOML. The most important difference being that white space is insignificant. It's specifically designed for writers. It is text-only as far as I can tell. Add booleans and it looks compelling.

Also interesting is Cuelang. Brackets are back but newlines replace commas. Any real language is better for config generation.

Nadrieril commented 3 years ago

Nickel by tweag.io looks very promising (from my pov as a Dhall dev, it solves many of the design issues Dhall has) (also tweag.io do neat stuff).

ghuntley commented 3 years ago

Nickel by tweag.io looks very promising (from my pov as a Dhall dev, it solves many of the design issues Dhall has) (also tweag.io do neat stuff).

Anything from tweag typically gets an automatic +1 from me. Raise the PR.

gellweiler commented 2 years ago

I mean I hate YAML, I really do. But I love standards and YAML has become de facto the standard for JSON like config files. So I'm going to keep using it in my software. It would be even worse to start switching everything to other config languages. I wish they would fix some things by creating an offical strict YAML standard tough. Something that has backward compatibility but that enforces clear rules of indentation, forces all strings to be wrapped by " and gets rid of most of the ambitions. Something that could be easily enforceable by linters and that minimalistic parsers could be written for.