On Fri, Sep 23, 2016 at 8:06 PM, Zachary Gershman <zgersh...@pivotal.io> wrote:
> I don't think the "I don't want this format in because I don't want to see > more of this format" doesn't work. People are going to keep using it, YAML > isn't a format that is going anywhere and I would love to know what you > would suggest most people switch to as an alternative (don't say TOML or > JSON). On one hand, adding YAML to the stdlib seems like a simple thing which is easy to do: pick the current solution out there and embed it. On the other hand, beware! Once added, it undergoes the Go 1.x contract of backwards compatibility, including subtle errors. If a library lives outside the stdlib, it has the ability to evolve in a freer way, on its own release cycle. My suggestion is to look at the interconnection needed in the stdlib for it to live outside. Are the current tools in place to make it as easy to interact with YAML as it is with JSON? If affirmative, keep hacking! If negative, think about what is missing and/or needed to make the interaction better. As for the quality of YAML as a format, I've had trouble with it on several occasions. Amazon has had YAML with files embedded in the YAML. Here, indentation plays a crucial role and it creates some subtle hard-to-debug errors quickly. Of course, these problems might have fixes which I don't know of, but the things I saw did not impress me. I also agree JSON is a bad format for configuration--it is far from a succinct format: S-expressions, or Erlang Terms, are usually simpler and shorter than JSON. And both of those formats are not exactly terse by themselves either. -- J. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
