Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of YAML

blog.atomist.com

Post reply on HN
Print view View original

81–90 of 173 posts

Re: In Defense of YAML

#81

Post by bmurphy1976 »

guitarbill wrote: post #75
bpicolo wrote: post #3

> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…

Ansible deserves some credit at least. It tried to avoid the pitfalls Chef and Puppet fell into, which is having a DSL that allows arbitrary logic, i.e. basically just a Ruby script. These become horrible to trace and debug. Ansible only allowed conditionals or loop constructs in some well-defined places, which actually does help when trying to comprehend Ansible playbooks. (Although one might still argue a strict DS…

I feel like there is a large gap between shell scripts and Ansible. If we draw a line, you end up with something like this, with each option bringing more power, but also complexity with it.

Bash/Make => ? => Ansible => Chef/Puppet/Salt => CFEngine

There's a big jump in complexity from Bash/Make to Ansible. This is a place where Python or Ruby would make a lot of sense but without all the dsl/yaml/declarative nonsense. A small library of reusable functions would fit in well here, written in a language that isn't fundamentally broken (bash).

Re: In Defense of YAML

#82

Post by marcyb5st »

krisrm wrote: post #73
marcyb5st wrote: post #39

Earlier quoted context omitted.

So, my opinion is based only on perhaps 1h playing with it. I have mixed feelings about this. It's definitely neat, but I don't like that it adds quite a bit of cognitive overhead (again, this might be because I'm not fully used to it). I believe configurations shouldn't force you to think "how will this be rendered?". For my personal projects I started using protobuffer text formats as configurations. Having the pro…

I agree with this sentiment. I work primarily in web dev, and the stacks are already so sprawling with different technologies... config file generation debugging just sounds like unnecessary hassle. Had not heard of protobuffers before though, and it does look pretty neat.

Glad to hear :) I must admit that protobuffers v2 might be best for configurations files, given that they have the "required" keyword on fields and the generated code has methods like "hasFieldX() -> bool" which proto v3 dropped in favor of simplicity.

Re: In Defense of YAML

#83

Post by syrrim »

lmm wrote: post #25
gaogao wrote: post #15

You can actually use Python as a configuration file pretty well, if you need more complicated logic and macros. Otherwise, sticking to a toml or ini file is my preference.

Are you gonna embed a Python interpreter into your C# programs though? Better to use something like dhall that's at least open to being loaded from multiple languages.

This is what IronPython was invented for.

Re: In Defense of YAML

#84

Post by ams6110 »

calibas wrote: post #63
onion2k wrote: post #58

Earlier quoted context omitted.

Three dots indicates the end of a block, not a document. Look at Example 2.8 in your link. If the user sends; --- time: 20:03:20 player: Sammy Sosa action: strike (miss) ... .. you can't know if they actually meant to send .. --- time: 20:03:20 player: Sammy Sosa action: strike (miss) ... --- time: 20:03:47 player: Sammy Sosa action: grand slam ... Also, in my experience, which is mostly limited to Ansible config bec…

They mark the end of a YML "document", but not the end of a YML "stream", which can contain multiple documents. It's the terminology that's causing confusion.

That's interesting, I have always seen the three dots as the first line in a YAML file, my exposure to YAML being almost exclusively Ansible configurations.

Re: In Defense of YAML

#85

Post by debug-desperado »

75dvtwin wrote: post #79
bpicolo wrote: post #3

> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…

Another potential option, is Lightbend Config https://github.com/lightbend/config It adds includes/inheritance, substitutions, unit of measure parity , comments , and few other things -- on top of JSON. does not have if-logic, loops, or arbitrary functions, however. On plus side, the library is available in a number of languages, easily embeddable. And there is an IntelliJ plugin for it, to color the syntax of the co…

HOCON is a very nice configuration format that should be preferred to JSON and YAML - it really deserves more adoption. I always reach for Lightbend Config on non-Spring projects.

Re: In Defense of YAML

#86

Post by AstroJetson »

I'm a big fan of using Lua for this. You can put all the configurations you want in a fairly readable format and then if you need to, custom Lua code to get process for the hard parts. The receiving end has the ability to decide if it wants to run the custom code or not for security reasons.

I saw the comment that Helm is going to include Lua, but not getting the advantage that Helm brings over base Lua.

Re: In Defense of YAML

#87

Post by maelito »

A substantial part of the french social and tax system is being coded as free software. One of the teams writes the source code in YAML.

It's not a programming language, but rather a specification for calculable parts of the law. A JS programm then generates Typeform-like simulators, a node library, and an online interactive documentation (it is now compulsory for french administrations to explain their algorithms).

I'm not sure YAML is the good long-term design choice, but as we can't afford to write our own language, it's bootstrapped the project successfully.

Here is the main file : https://github.com/betagouv/syso/blob/master/source/règles/b... Don't be afraid by the number of lines, it's just a collection of variables.

Re: In Defense of YAML

#88

Post by virtualized »

mirages wrote: post #72

I'm usally confronted at YAML when I setup gameservers of some indie games (I'm looking at you Empyrion) and I find it extremely painful to handle. When you have sevral configuration files where you have to change/tweak data I always end up pulling my hairs why stuff isn't working because of an extra space lying anywhere in the file. Please don't use YAML for anything that has to be edited by a human INI, XML, JSON a…

It's weird how languages like YAML, XML and JSON are very much designed for communication between machines, but are still the default choice for human input. Actual programming languages - designed for use by people - are rarely considered for high level configuration.

I have actually seen something similar to this happen:

1. We just need a few configuration options. Let's add an XML configuration file.

2. Keeping all the configuration files in sync for different environments is a lot of work and really error-prone. Let's generate all the configuration files. What about an XML meta-configuration file?

3. Some things are different between environments. We need conditionals in our XML meta-configuration language.

4. There is a lot of repetitive configuration. It would be more maintainable if we had loops, variables, integers, string interpolation, functions, ... in our XML meta-configuration language.

Great, now we invented our own awful programming language that lacks any tooling, documentation or libraries and isn't compatible with anything else.

Re: In Defense of YAML

#89

Post by bmurphy1976 »

boleary-gl wrote: post #68
arkadiytehgraet wrote: post #5

I highly agree with inappropriateness of YAML for GitLab CI/CD configuration. It does work for simple use cases and/or in small repositories - however, doing something slightly more complicated than a simple build/test/deploy pipeline takes an immense effort, with a range of hacks and workarounds. Even the simplest things, like passing some data (e.g. a link) from one job to another requires quite an overhead (either…

GitLab PM for Verify (CI) here. I agree that a lot of complex pipelines can be tough to express in YAML. One of our key focuses this year is to make advanced use cases for GitLab CI/CD more lovable. Specifically, you can see the overall direction here: https://about.gitlab.com/direction/verify/ . Some specific issues I'd love feedback from the community on that I'm thinking about are: * Directed acyclic graphs (DAG)…

DAG's are good. Let me define a DAG in imperative code (any language I want) using any techniques I want, then I hand the DAG off to you and you execute it. Anything else is introducing complexity for complexities sake.

Re: In Defense of YAML

#90

Post by merlincorey »

k__ wrote: post #71
scirocco wrote: post #64

Earlier quoted context omitted.

Would you expect all sysadmins to become programmers?

Maybe some will? My take is: The complex admin work will be going to the cloud providers. The rest (besides some niche stuff) will get so simple a programmer can do it on the side. Admins that don't learn to program are left behind. Only those who have some cushy full time employment, were they can't be let go, will remain.

> Admins that don't learn to program are left behind. Only those who have some cushy full time employment, were they can't be let go, will remain.

While I personally am a Software Engineer + Systems Engineer combination perfect for modern Devops... I do not agree with you one bit.

There will always be a place for non-programming systems administrators -- especially as we get more and more systems over time.

Will those administrators be able to /scale/ to managing 100s or 1000s of system without learning some sort of programming language or configuration management system? Probably not.

However, there are plenty of businesses out there that only have a handful of servers and services which can totally (and more cheaply) be managed manually.

Automation has an up-front cost that doesn't always make sense for the business to spend.

Post reply on HN