-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest some alternatives #2
Comments
Indeed it would. Send in a PR! |
As I said, I'm not really aware of any (except maybe TOML). |
Maybe code. Just simple code. Anything would do. C#, go, Ts, etc |
Send in a PR! |
…TOML 😄 👍 (not used though) |
The problem is that the different articles linked criticise different things. SerializationSerialization 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 specIt'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... YAMLAnd I disagree — apart from its obscure spec and quirks, YAML is great. I use TOML (because of
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. |
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 #2 (comment). Have added the section for now. |
cool, thanks! |
|
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. |
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. |
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. |
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)?
The text was updated successfully, but these errors were encountered: