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

71–80 of 173 posts

Re: In Defense of YAML

#71

Post by k__ »

scirocco wrote: post #64
q3k wrote: post #21

Earlier quoted context omitted.

From what I've experienced, it's mostly tools that target either sysadmins or sysadmins-turned-pseudo-devops, and those tools pretend that anything can be done with 'just configuration' as a marketing point. Programming is for programmers, you see. It's easy for someone who never {wanted to, learned to} program to accept yet another configuration format (with all options specified up front) and then accidentally lear…

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.

Re: In Defense of YAML

#72

Post by mirages »

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 are all formats that are more forgivable regarding that (oh and always trim anything you parse. The more you do to help against accidental input, the less admins you'll have ;)

Re: In Defense of YAML

#73

Post by krisrm »

marcyb5st wrote: post #39
jasonhansel wrote: post #29

I really want a good "universal" configuration language (like https://dhall-lang.org/ ) that can be used to generate arbitrary text files (e.g. nginx configurations, JSON, YAML, etc.)

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.

Re: In Defense of YAML

#74

Post by jopsen »

q3k wrote: post #26
joshlemer wrote: post #6

Earlier quoted context omitted.

What about https://dhall-lang.org/ ?

Also https://jsonnet.org/ . Both of them are basically BCL/GCL but with some semantic/scoping horrors removed.

I was involved with json-e a while ago: https://taskcluster.github.io/json-e/

Which to me seemed more intuitive.

But I'm also pretty excited about the UI-as-code features happening in Dart: https://medium.com/dartlang/making-dart-a-better-language-fo...

Mostly I prefer YAML w. json-e because it's declarative and expressive enough for those few cases where you needed fancy stuff..

But the new Dart features coming up, makes me think I could write config as code -- we'll see :)

(Disclaimer: I work at Google)

Re: In Defense of YAML

#75

Post by guitarbill »

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 DSL would offer the best of both worlds.)

Re: In Defense of YAML

#76

Post by zeveb »

Alternatively, if you're programming and you want a structured data format, use S-expressions! They are basically tailor-made for exactly this problem.

    (gitlab:assets:compile
     #%dedicate-no-docs-pull-cache-job
     (image "dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.5.3-git-2.18-chrome-71.0-node-8.x-yarn-1.12-graphicsmagick-1.3.29-docker-18.06.1")
     (dependencies
      setup-test-env)
     (services
      (docker stable-dind))
     (variables
      (NODE_ENV production)
      (RAILS_ENV production)
      (SETUP_DB false)
      (SKIP_STORAGE_VALIDATION true)
      (WEBPACK_REPORT true)
      ;; we override the max_old_space_size to prevent OOM errors
      (NODE_OPTIONS "--max_old_space_size=3584")
      (DOCKER_DRIVER overlay2)
      (DOCKER_HOST "tcp://docker:2375"))
     (script
      "node --version"
      "yarn install --frozen-lockfile --production --cache-folder .yarn-cache"
      "free -m"
      "bundle exec rake gitlab:assets:compile"
      "time scripts/build_assets_image"
      "scripts/clean-old-cached-assets")
     (artifacts
      (webpack-report
       (expire-in 31d)
       (paths
        "webpack-report"
        "public/assets/"))))
And that’s just a first cut; it could be made much nicer.

Re: In Defense of YAML

#77

Post by kevin_thibedeau »

joshlemer wrote: post #6
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…

What about https://dhall-lang.org/ ?

You can make Tcl as non-Turing complete as you wish. Stripped of most or all builtin commands, it becomes a flexible configuration language. You can add back power in small controlled doses as it becomes necessary. You can also make it more palatable to the cool kids by adding infix assignment and expression evaluation with a few simple helper procs.

Re: In Defense of YAML

#78

Post by jfoutz »

cube2222 wrote: post #14
k__ wrote: post #8

Earlier quoted context omitted.

I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?

Because the tools only support markup languages, so we have to use stuff like Jinja or go templates to create those.

With salt at least, that .sls file can just as easily be python. Just return the structure you need.

Re: In Defense of YAML

#79

Post by 75dvtwin »

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 config files.

Re: In Defense of YAML

#80

Post by linuxftw »

k__ wrote: post #50
cube2222 wrote: post #14

Earlier quoted context omitted.

Because the tools only support markup languages, so we have to use stuff like Jinja or go templates to create those.

Sure thing, but Jinja looks like a garbage fire. Why couldn't they use a regular programming language to create the markup? I mean this is done with HTML and JS all the time.

jinja is great, IMO, and well suited for it's intended purpose.

jinja is in wide use in the python community.

Post reply on HN