TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

YAML: Probably not so great after all (2019)

107 点作者 wheresvic3大约 5 年前

22 条评论

mxscho大约 5 年前
Earlier discussions:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17358103" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17358103</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20731160" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20731160</a>
hn_throwaway_99大约 5 年前
One of my favorite bugs of all time, which turns out to be a pretty common yaml bug (the article touches on a similar example), was when we used yaml to configure some localizable data. Everything worked fine until Norway came online. Sweden worked fine, so did Denmark and every other country, but the app crashed when it loaded the config for Norway.<p>Turns out the country code for Norway, &quot;no&quot;, is interpreted as boolean false when unquoted in yaml.
评论 #22849564 未加载
评论 #22849245 未加载
评论 #22849736 未加载
评论 #22848865 未加载
评论 #22849534 未加载
评论 #22848953 未加载
_bxg1大约 5 年前
I&#x27;ve never understood the love for significant whitespace. I see where the idea came from - &quot;No more missing semicolon errors! Woohoo!&quot; - but it should&#x27;ve been clear after trying out the idea for five minutes that it was not at all worth it. It constantly causes trouble and all just to save a couple of keystrokes.<p>Though: now that I think about it, most of the problems happen at the block level, not the line level. So maybe significant newlines are fine but not indentation.
评论 #22849237 未加载
评论 #22848951 未加载
评论 #22849144 未加载
评论 #22849731 未加载
eyelidlessness大约 5 年前
Nearly every time I have to make any changes to a CI environment (or set one up for a new project), I end up with a stream of increasingly unintelligible and often increasingly grumpy commit notes. It&#x27;s almost always because YAML, as a format, is confusing and frustrating to write.<p>Structured data with only vague, and often misleading, indication of its structure is awful to work with. Sure, it&#x27;s &quot;human readable&quot;, but if your data is of any real complexity you&#x27;re almost certainly better off just machine-generating it.
评论 #22849186 未加载
teknopaul大约 5 年前
Heartily agree with this post.<p>One of the things I most dislike about yaml is that they persuaded JSON to remove comments from the spec for some psuedo compatability nonsense. Without comments, json is less useful for config files and working&#x2F;documented examples.<p>I have written a pre-parser to permit comments in JSON and for nodejs apps I use javascript as config. Naturally where security is not a concern.<p>Yaml always seemed like a mess to me.<p>Liking Toml, decent compromise.<p>And linux style: name space value, hash and semi for comments. Unless I really need a heirachy.
评论 #22849279 未加载
topkai22大约 5 年前
I find YAML distressingly hard to work with. Just one example- because it’s white space delimited, copying and pasting a block of code will often blow up between docs based on nesting levels. This is intensely frustrating when the setting is tied to a CI pipeline that takes 5 minutes to get to the error.<p>The human unreadability if JSON is greatly exaggerated. While you can get horrible looking JSON, you can also then pretty print it into something much better. If we could just all agree to allow comments into a spec it’d be fine.
评论 #22849070 未加载
jrochkind1大约 5 年前
Since he opens by referring to a similar argument against JSON for human-editable configuration files, I wondered what format he did like for that. Answer at the end appears to be TOML, if you must have one at all.<p>&gt; Don’t get me wrong, it’s not like YAML is absolutely terrible – it’s probably better than using JSON – but it’s not exactly great either. There are some drawbacks and surprises that are not at all obvious at first, and there are a number of better alternatives such as TOML and other more specialized formats.<p>&gt; One good alternative might be to just use commandline flags.<p>&gt; If you must use YAML then I recommend you use StrictYAML, which removes some (though not all) of the more hairy parts.<p>(I do agree YAML is in retrospect a mistake. The reasons why remind me in some ways of the problems with Markdown).<p>(Oddly, I can&#x27;t seem to find an up to date TOML parser in ruby that supports the 1.0 spec...)
crehn大约 5 年前
Fun fact: YAML is a superset of JSON. That is, any JSON is also valid YAML.<p>YAML is a complex and unintuitive mess that allows doing every thing in a million ways. I’m surprised it ever got so much traction. TOML is a breath of fresh air next to it.
评论 #22851168 未加载
评论 #22849510 未加载
评论 #22849417 未加载
评论 #22849468 未加载
评论 #22849750 未加载
moron4hire大约 5 年前
Wait, what? It&#x27;s built in to the format that it can execute arbitrary shell commands?<p>&quot;Who approved this?!&quot;<p>I can&#x27;t imagine the cluster fuck of ideas in a person&#x27;s head to lead to thinking that this was an ok design for a configuration file. The person who designed this and I just don&#x27;t live on the same planet.<p>And here I thought the reason I didn&#x27;t use YAML was because the syntax looked stupid.
评论 #22849743 未加载
Animats大约 5 年前
YAML allows escapes to executable code?<p><pre><code> !!python&#x2F;object&#x2F;apply:os.system args: [&#x27;ls &#x2F;&#x27;] </code></pre> Who put that backdoor in?
评论 #22851245 未加载
pmoriarty大约 5 年前
My biggest gripe with YAML is its meaningful whitespace.<p>Debugging nearly invisible indentation problems can be such a pain.
评论 #22848898 未加载
评论 #22848942 未加载
nojvek大约 5 年前
When I first saw json, compared to XML, it was so simple. As a fairly new programmer I could say to myself “hey I can write a parser and dumper for this quite easily”.<p>When I first saw YAML, it was nice but it felt a bit too complicated.<p>All I really want is Indented JSON. New lines instead of commas. That’s it.<p>Json is fast to parse. See simdjson doing it at &gt; 2.5GB&#x2F;s. One can’t do this with YAML where no could mean many things.<p>And god I hate k8s for their bajillion yaml configs. Thank god for jsonnet that can dump to yaml. Jsonnet is truly nice and makes working with json like configs a pleasure.
save_ferris大约 5 年前
I see a lot of criticism of YAML, and I’ve looked a few other minimal configuration languages like TOML as well.<p>Serious question: why doesn’t this language space have a universally adopted candidate like SQL?
评论 #22849006 未加载
评论 #22848952 未加载
karussell大约 5 年前
It is so easy to complain about something, but seriously: what are the alternatives for human readable config files?
评论 #22849692 未加载
评论 #22849507 未加载
评论 #22850741 未加载
评论 #22848965 未加载
评论 #22849929 未加载
评论 #22849234 未加载
Mikhail_Edoshin大约 5 年前
The specification of YAML is about three times as long as XML 1.0, but while XML includes a whole grammar-based validator with such niceties as referential integrity of IDs and default values for omitted parameters, YAML spends all this on syntactic sugar.
rs23296008n1大约 5 年前
YAML isnt my idea of clarity but thats fine. I tend to go with using a python script to generate a json file. This supports comments, if-else decision making, modules and all sorts of other smarts. Tell users not to edit the resulting json file - its readonly.<p>Python gives you all the power of scripting including validation and json gives you the easily readable format for both humans and machines. Great for knowing exactly what the settings evaluated as.<p>And when you don&#x27;t need the power of full expressive python script, you can just json.dump() a python dictionary and be done with it.<p>I&#x27;ve also used sqlite as a config file format and that is very polite and easily read from anything I use.
rudolph9大约 5 年前
<a href="https:&#x2F;&#x2F;cuelang.org" rel="nofollow">https:&#x2F;&#x2F;cuelang.org</a> is a very nice alternative that has nice import&#x2F;export support for yaml among others
mrbonner大约 5 年前
I have not seen anything that could come close to the robustness and flexibility XML has to offer. When being used for configuration XML seems to be the superior choice. People tend to give XML a bad name in RPC usage for being verbose. But, for config it’s perfect for me.<p>There are tons of IDEs supporting XML (syntax highlight &amp; collapsing brackets, etc...). XML schema is also great to ensure the config is conforming. I keep thinking we are trying to reinvent a worse wheel here.
beefbroccoli大约 5 年前
I just recently replaced a bunch of YAML in a project with JSON. At face value the YAML still <i>looks</i> easier to grok, but I kept needing to periodically think about YAML&lt;-&gt;JSON. At one point in the middle of yet again running JSON through a YAML conversion process to see how I would write something, it dawned on me that YAML wasn&#x27;t saving making my life easier it was making it harder.
cachestash大约 5 年前
The opening sentence is incorrect.<p>yaml.load is now a wrapper around yaml.safe_load that negates the risks he highlights
azaras大约 5 年前
YAML in kubernetes works very well.<p>If yaml is not working for you have to search a serializer format that fit in your project.<p>There is not silver bullet.
评论 #22849111 未加载
评论 #22849950 未加载
评论 #22850013 未加载
mixmastamyk大约 5 年前
Use strict yaml, solvable problems solved.