I'll ditto what Jesper said. Go's stdlib is fairly stable and coherent. YAML library does not support encoder/decoder that you can use with arbitrary io.Reader/Writers to marshall/unmarshall stuff. YAML as a spec if very messy. It allows embedding variables which has been exploited to hack backend apps (rubygems e.g). Buts thats more related to the spec. I dont see any obvious pain in keeping it outside the stdlib, as long as its maintained (Gustavo doing an aweseom job already)
On Fri, Sep 23, 2016 at 11:19 AM, Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > > 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. > -- 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.
