Is there a YAML parser implementation in Go that doesn't look like a result of transpilation from C?

xuanbao · · 737 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I.e. <strong>idiomatic</strong>, + stable and actively maintained one.</p> <p>Alternatively, what other configuration formats would you consider to represent the data structure below?</p> <pre><code>myCommands1: - print: &#34;Some text&#34; - run: some command - run: some other command - kill: ... - print: &#34;Done&#34; </code></pre> <p>JSON would be too verbose, wouldn&#39;t it? XML?</p> <hr/>**评论:**<br/><br/>sontags: <pre><p><a href="https://github.com/go-yaml/yaml">https://github.com/go-yaml/yaml</a> is considered a de facto standard... XML would be a bit of an odd choice if JSON is to verbose... TOML? <a href="https://github.com/BurntSushi/toml">https://github.com/BurntSushi/toml</a> for example</p></pre>r3drocket: <pre><p>I&#39;ve used this one and I like it, although I feel it is a little too strict sometimes as I end up spending lots of time hunting down syntax errors in my yaml that I can rarely see easily. It might just be me and my use case. </p></pre>jmoiron: <pre><p>It might just be yaml and its invisible syntax.</p></pre>zenberserk: <pre><p>TOML and JSON suffer from the overhead of escaping all strings with quotes. </p> <p>I have similar needs, and decided to stick to YAML. TOML offers the most consistent format (YAML &amp; JSON support inline structs, YAML string interpretation can be tricky, e.g unescaped yes/no/true/false are interpreted as boolean by default), so to compensate I borrowed the &#34;go fmt&#34; concept and implemented my own YAML formatter (some structs are better maintained inline, others as verbose-tab-separated blocks).</p></pre>whippythellama: <pre><p>I&#39;m looking at Viper (<a href="https://github.com/spf13/viper">https://github.com/spf13/viper</a>) for a project I&#39;m currently working on. It handles YAML, TOML, JSON, and a number of other formats. I like it for that, and because it can read from a remote (a la etcd) configuration source, and basically appears to take care of a lot of config-related plumbing that I would otherwise have to sink a bunch of time into. Caveat: I&#39;m still evaluating it myself, so I don&#39;t have much in the way of real-world experience with it yet.</p></pre>doesntgolf: <pre><p>I&#39;m currently using viper in my main project and it&#39;s been excellent. Would recommend.</p></pre>fatcatthebrat: <pre><p>hcl is cool too</p></pre>cathalgarvey: <pre><p>Here&#39;s a really naughty solution: use Gopher-lua as a massively overpowered configuration language, like I did with <a href="https://github.com/cathalgarvey/listless" rel="nofollow">listless</a>. :)</p></pre>metamatic: <pre><p>Looks like a natural for TOML, or even just a simple /bin/sh-style parser with the first word before whitespace being the command.</p> <pre><code>define myCommands1 print Some text, no escaping needed. run some command kill thing print Done end define myCommands2 ... </code></pre></pre>baijum: <pre><p>May be you can try TOML: <a href="https://github.com/pelletier/go-toml" rel="nofollow">https://github.com/pelletier/go-toml</a></p></pre>sharptierce: <pre><p>I think xml is much more verbose than json. But I prefer both over yaml. </p> <p>XML wins since it can have comments ;)</p></pre>Growlizing: <pre><p>Yaml can have comments.</p></pre>sharptierce: <pre><p>yeah that&#39;s true. I&#39;m sorry I&#39;m just biased there. </p></pre>blueblank: <pre><p>Why do you dislike YAML? I do not understand why there is dislike for YAML. Given xml, json, or yaml, yaml is the most human writeable of the three, and once encoded you can put it into the most readable format needed by situation. </p></pre>weberc2: <pre><p>I don&#39;t mind it, but yaml is complex and good docs are hard to find. JSON is familiar and simple for many devs.</p></pre>hayzeus: <pre><p>Yaml&#39;s fine until it gets really nesty. </p> <p>JSON&#39;s fine, but its easy to screw up the syntax, and as others have pointed out strings have to be escaped. TOML is pretty nice, although it still suffers from string escaping issues. I used TOML for <a href="https://github.com/mowings/scylla" rel="nofollow">https://github.com/mowings/scylla</a> and was pretty happy with it, but nested quotes can still be a hassle.</p></pre>sharptierce: <pre><p>I don&#39;t like indentation based stuff (ruby, yaml, etc). It&#39;s just a matter of personal preference. </p></pre>rozzlapede: <pre><p>Definitely agree with your sentiment on this aspect of Yaml. I really like it personally, but when I introduce it into a team project I end up having to write a git hook to try parsing any commits to the Yaml files because unfamiliar devs have their IDEs set to tabs instead of spaces.</p></pre>sharptierce: <pre><p>nice workaround though :-)</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

737 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传