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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

The Yaml document from hell

566 点作者 ruuda超过 2 年前

83 条评论

dig1超过 2 年前
&gt; is that for a long time it was the only viable configuration format<p>Actually, this is not the case. We had INI format for simple stuff and XML (protected with entire schema) for complex things many years ago, which worked. Yet, we wanted something readable (like INI), but able to express complex types (XML).<p>I don&#x27;t think Toml is a viable replacement - for me, it has an INI-level of simplicity with even worst hacks to have nested structures. But, give it time and you&#x27;ll have another YAML.<p>But yes, YAML is confusing for edge cases (true&#x2F;false, quoting), but I&#x27;m going to find a powerful replacement that is not XML. Maybe EDN can jump in, but for anything more complex, I&#x27;d rather have a Lisp interpreter and structures around than any of mentioned and upcoming formats.<p>Thinking that JSON is a suitable replacement, imagine writing Ansible or k8s stuff in it; that would be fun ;)
评论 #34351883 未加载
评论 #34352033 未加载
评论 #34354708 未加载
评论 #34356044 未加载
评论 #34352315 未加载
评论 #34352177 未加载
评论 #34352072 未加载
评论 #34357105 未加载
评论 #34352009 未加载
评论 #34357947 未加载
评论 #34351970 未加载
评论 #34358252 未加载
chrizel超过 2 年前
I&#x27;ve never met anyone who say&#x27;s &quot;I like YAML, it is great&quot;... most people that worked with it say something like &quot;YAML is annoying, I don&#x27;t like it&quot;...<p>While introducing Kubernetes at our company in the last two years, we are currently in a process going more and more away from YAML with internal Helm charts to a much simpler process by just using HCL and Terraform, and defining Kuberentes resources as Terraform resources.<p>As a software developer HCL just makes so much more sense than this YAML + Helm + Go templates hell, which feels like C preprocessor hell all over again. Other solutions like kustomize are neat, but I don&#x27;t see how all of these YAML workarounds should be better than something like HCL with Terraform. HCL feels like a real declarative programming language (with real conditions, variables, a module system and useful built-in functions). YAML feels like another more complex JSON and other tools like Helm or Kustomize try to work around the weaknesses of YAML with some kind of templating system.<p>YAML looks nice to read in simple demos and in small files, but is just not adequate in the real world (in my personal opinion - I know that YAML is used by a lot of people in production as of today).
评论 #34352050 未加载
评论 #34352047 未加载
评论 #34352019 未加载
评论 #34351902 未加载
评论 #34353436 未加载
评论 #34353198 未加载
singingfish超过 2 年前
YAML is nuts, and JSON is annoying (trailing comma limitations, lack of comment syntax no matter how annoying it is that the spec is correct about why there are no comments).<p>Both have their place though. YAML came out of perl, and both are some confluence between awesome and horriffic (although yaml wins the horrific crown for sure).<p>I&#x27;ve had a little bit to do with Ingy - the inventor of yaml, and I&#x27;ve worked closely with some of his collaborators. Ingy is nuts, mostly in a good way, but I wouldn&#x27;t put him in charge of the architecture, I&#x27;d put him in charge of the abyss.
评论 #34352849 未加载
评论 #34353022 未加载
评论 #34352527 未加载
评论 #34354817 未加载
评论 #34352451 未加载
评论 #34354151 未加载
评论 #34352764 未加载
评论 #34354909 未加载
bambax超过 2 年前
I never could understand the hate XML got, but I&#x27;m having a bit of schadenfreude seeing what people suffer through with its replacements.<p>An XML document with a well-thought-out domain-specific DTD would solve all these problems; instead, we have something where <i>no</i> sometimes means <i>false</i> (but not always) and <i>22:22</i> sometimes means <i>1342</i> (but not always!)... because... why not?!?<p>All that horrible mess, it seems, because people didn&#x27;t like to have to close tags.
评论 #34352168 未加载
评论 #34352946 未加载
评论 #34352159 未加载
评论 #34352427 未加载
评论 #34352874 未加载
评论 #34352190 未加载
评论 #34353989 未加载
评论 #34352283 未加载
评论 #34353203 未加载
评论 #34352166 未加载
评论 #34352367 未加载
评论 #34352558 未加载
评论 #34353014 未加载
评论 #34353087 未加载
评论 #34353926 未加载
评论 #34352553 未加载
评论 #34352797 未加载
评论 #34353117 未加载
评论 #34352804 未加载
jrmg超过 2 年前
I do think YAML is overly complex - but there is some hyperbole in this document.<p>- Many of these complaints are about YAML 1.1.<p>- YAML 1.2 was released _14 years ago_.<p>- The author makes some allusions to 1.2.2, and it requiring a team of people 14 years to make, but, from the yaml.com announcement they link to: “No normative changes from the 1.2.1 revision. YAML 1.2 has not been changed”<p>I guess my first two comments are undercut by PyYAML using YAML 1.1 (Really?! Python’s had 24 years of the Norway problem?!)
评论 #34354954 未加载
评论 #34352219 未加载
sandwell超过 2 年前
Agree with the final part of this article that &quot;programmable&quot; configuration languages like Nix and Dhall are the way forward.<p>I&#x27;ve spent a lot of time writing YAML for Ansible, Cloudformation, k8s, Helm, etc. Some of the issues this article mentions are pitfalls but once you get a bit of experience with it, you know what to look out for.<p>I&#x27;ve also spent and a lot of time writing Nix expressions, which is much more &quot;joyful&quot; IMO. Seemingly simple features like being able to create a function to reuse the same parameterized configuration makes life much easier.<p>Add in a layer of type safety and some integration with the &#x27;parent&#x27; app (think replacements for CloudFormation&#x27;s !GetAtt or Ansible&#x27;s handlers), the ability to perform basic unit tests, then configuration becomes more like writing code which I consider a good thing.
milliams超过 2 年前
Almost all those problems are solved by marking up the strings as strings, using &quot; and &quot;.
评论 #34351917 未加载
评论 #34352892 未加载
评论 #34390928 未加载
评论 #34351989 未加载
the-alchemist超过 2 年前
Since everyone seems to throwing their favorite format into the ring (), I will too: EDN [0]<p>* no enclosing element (i.e., can be streamed)<p>* maps, lists, even sets<p>* tags (like &quot;Person&quot;. UUIDs and timestamps are built-in tags)<p>* floating point numbers<p>* integers<p>* comments<p>* UTF-8<p>* true booleans<p>* no need to worry about too many or too few commas in the right or wrong place<p>Implementations in almost every language under the sun [1].<p>The format is simple enough that it&#x27;s easy to implement, verify, and test. No strange string interpretation craziness (see YAML and &quot;Norway problem&quot;), no ambiguity between FP and integers (see JSON), comments. And if your editor has rainbow parenthesis support, reading is actually a pleasant experience.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;edn-format&#x2F;edn">https:&#x2F;&#x2F;github.com&#x2F;edn-format&#x2F;edn</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;edn-format&#x2F;edn&#x2F;wiki&#x2F;Implementations">https:&#x2F;&#x2F;github.com&#x2F;edn-format&#x2F;edn&#x2F;wiki&#x2F;Implementations</a>
评论 #34356951 未加载
r3trohack3r超过 2 年前
&gt; loading an untrusted yaml document is generally unsafe,<p>TIL and this is... Not great?<p>I often parse JSON as YAML. Since YAML is a superset of JSON, all valid JSON files parse as a valid YAML file too, but now you can add comments to your JSON since YAML has comments. Didn&#x27;t know I was opening my process up to code execution doing this...<p>Knowing this, YAML is dead to me as a format. This really seems unacceptable for a markup parser.
评论 #34355673 未加载
评论 #34355439 未加载
评论 #34355457 未加载
rqtwteye超过 2 年前
At least YAML has comments, which JSON doesn&#x27;t. I know people will say &quot;JSON is not meant as config format&quot; but in reality it is used as such.<p>In general I don&#x27;t understand why there is so much churn and focus on config file formats. They can be annoying but in the end the real problem is that we have complex configurations so a different format is not going to help much.<p>Personally I prefer YAML over XML or JSON for config because I don&#x27;t have to worry about closing brackets or braces. Maybe we need a good editor to make editing them easier.
nathell超过 2 年前
EDN’s my favourite config format.<p>+ Simple (like JSON)<p>+ Has comments<p>+ Extensible<p>+ Built-in sets, UUIDs &amp; timestamps<p>+ Well-suited to configuration (cf. Aero)<p>+ Lispy (well, Clojurey)<p>- Lispy (well, Clojurey)<p>- Handwavey specs<p>- Not widely supported
评论 #34353094 未加载
jwilk超过 2 年前
&gt; In Python, you can avoid this pitfall by using yaml.safe_load instead of yaml.load.<p>It&#x27;s harder to make this mistake in Python these days. yaml.load(input) has been depreacted since PyYAML 5.1 (<a href="https:&#x2F;&#x2F;github.com&#x2F;yaml&#x2F;pyyaml&#x2F;wiki&#x2F;PyYAML-yaml.load(input)-Deprecation">https:&#x2F;&#x2F;github.com&#x2F;yaml&#x2F;pyyaml&#x2F;wiki&#x2F;PyYAML-yaml.load(input)-...</a>) and finally stopped working in 6.0.
jasode超过 2 年前
<i>&gt;The literals off, no, and n, in various capitalizations (but not any capitalization!), are all false in yaml 1.1, while on, yes, and y are true. </i><p>Fyi... I looked at PyYAML source code and the parser code omitted single-character &#x27;y&#x27; in the regex. Previous comment: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26681295" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26681295</a>
评论 #34365500 未加载
avereveard超过 2 年前
&quot;Parsing json is easy&quot;<p><a href="https:&#x2F;&#x2F;seriot.ch&#x2F;projects&#x2F;parsing_json.html" rel="nofollow">https:&#x2F;&#x2F;seriot.ch&#x2F;projects&#x2F;parsing_json.html</a><p><a href="https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;nst&#x2F;JSONTestSuite&#x2F;master&#x2F;results&#x2F;pruned_results.png" rel="nofollow">https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;nst&#x2F;JSONTestSuite&#x2F;master&#x2F;r...</a>
评论 #34352231 未加载
评论 #34351873 未加载
评论 #34354694 未加载
xg15超过 2 年前
&gt; <i>Json is so obvious that Douglas Crockford claims to have discovered it — not invented.</i><p>I mean, it&#x27;s called &quot;JavaScript Object Notation&quot; for a reason. From what I know, the beginnings of it really were in the early days of AJAX: People were looking for a good way to encode complex data structures in dynamically generated script tags.<p>Then someone stumbled over essentially a random syntax element in JavaScript that turned out to be extremely well-suited for that task.<p>So I think talking about &quot;discovering&quot; JSON as a JS syntax feature which later became its own thing is quite correct here.
PurpleRamen超过 2 年前
YAML seems like a good that gets harmed by feature-creep. All I want when using YAML is a simple human-friendly text-format for slightly structured data. But all those special features and edge cases...as if I even have the time to learn about them. Values should be only text. Outside of the handful clear specified cases of numbers and maybe true&#x2F;false&#x2F;none, they should not have any other interpretation on the parser.<p>Isn&#x27;t there something like a simple YAML-definition and some YAMl-schema for the powerusers?
评论 #34353095 未加载
评论 #34353151 未加载
评论 #34354630 未加载
评论 #34353090 未加载
loa_in_超过 2 年前
There&#x27;s a lot of alternatives out there. One of the most complete (in terms of specification) and very promising is concise encoding (<a href="https:&#x2F;&#x2F;concise-encoding.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;concise-encoding.org&#x2F;</a>) which focuses on the duality of editable human compatible representation (as text) and efficient binary encoding&#x2F;decoding. The biggest issue right now is lack of actual implementations. The project is open source (I&#x27;m not affiliated with it).
danjc超过 2 年前
In the linked YouTube video talking about JSON: &quot;People were putting instructions to the parser in comments... so I [removed] the comments.&quot; - Douglas Crockford.<p>Let the impact of that sink in - that decision has almost certainly literally cost millions of developer hours! In fact, the article actually claims that the lack of comments in part led to YAML itself so by implication...<p>I jest (sorta) but what a great example of an initially helpful decision having last consequences.
评论 #34352090 未加载
评论 #34352513 未加载
marc_omorain超过 2 年前
At CircleCI, we have had to handle many strange YAML documents. Two that come to mind:<p>A recursive document:<p><pre><code> key: &amp;anchor - *anchor </code></pre> The `~` character represents null:<p><pre><code> ~: - ~ </code></pre> This parses as a map of {null: [null]}
评论 #34352407 未加载
d12bb超过 2 年前
When I first discovered YAML, I loved it&#x27;s apparent simplicity. Nowadays, I sigh every time I have to use it and am very happy with the Rust world having mostly adopted TOML.
polyrand超过 2 年前
I wonder why generated JSON is not used more widely, something like jsonnet[0], although I&#x27;ve never used it.<p>Most systems come with Python 3 installed, which supports working with JSON[1] without installing any dependencies. So, I&#x27;m wondering if we could use Python to generate JSON data that is then consumed by other tools. This would fix the lack of comments and trailing commas in JSON, you get functions and other abstractions from Python, and you don&#x27;t need to install any third-party tools (vs. something like jsonnet).<p>[0]: <a href="https:&#x2F;&#x2F;jsonnet.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsonnet.org&#x2F;</a><p>[1]: <a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;json.html" rel="nofollow">https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;json.html</a>
评论 #34352561 未加载
politelemon超过 2 年前
Isn&#x27;t TOML just the .INI files of yore? At least it looks very similar.
评论 #34351792 未加载
jwilk超过 2 年前
&gt; yaml is a superset of json<p>This is oft-repeated, but incorrect claim:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30052633" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30052633</a>
PaulHoule超过 2 年前
About<p><pre><code> Sometimes an application will start out with a need for just a configuration format, but over time you end up with many many similar stanzas, and you would like to share parts between them, and abstract some repetition away. This tends to happen in for example Kubernetes and GitHub Actions. When the configuration language does not support abstraction, people often reach for templating, which is a bad idea for the reasons explained earlier. Proper programming languages, possibly domain-specific ones, are a better fit. Some of my favorites are Nix and Python </code></pre> Templating is fine with YAML if you don&#x27;t do it with strings but with a system that turns one YAML document into another YAML document, that is, do your substitutions in the YAML universe.<p>The &quot;code up your configuration in your favorite programming language&quot; can really work but it frequently becomes a point of frustration itself. As much as I want to like YAML it has a number of intrinsic problems like the Norway problem... But I do think people are confusing the accidental and essential complexity and because of that they flinch and reach for non-solutions to the problems of configuration rather than really thinking it through.
harshreality超过 2 年前
I don&#x27;t get all the YAML hate. The article even mentions solutions, which are all better than adopting some nonstandard json variant or toml.<p>- for whatever language you&#x27;re using, be aware of which YAML version its YAML library supports and its defaults, and how to safe load yaml in that language.<p>- defensively quote strings, particularly if you&#x27;re on a language with an antiquated yaml library that defaults to yaml 1.1.<p>- defensively use true&#x2F;false only, and proactively convert any other booleans in your codebase to true&#x2F;false.<p>- Depending on your language, you can avoid any custom data types for any externally-distributed applications to mitigate the risks, even when it might make things more convenient. Use safe loading (most languages with yaml libs support it) to avoid loading any. The other major YAML alternatives that YAML haters recommend won&#x27;t have custom data types either.<p>Features like references and folding semantics are very convenient, and you don&#x27;t even have to use them. Basic yaml enjoys better readability than json. toml is only fine if you don&#x27;t have much nested data.<p>The author&#x27;s note that there are json <i>variants</i> that help with some json failings makes no sense. If you&#x27;re going to adopt some non-standard json variant, why not just adopt yaml 1.2, make sure your language has a yaml lib that supports it, and use that? At least yaml 1.2 is standardized. It&#x27;s not their fault if python&#x27;s libyaml only supports yaml 1.1. It looks like pyyaml is essentially in maintenance mode and ruamel.yaml is what everyone should be using? Unfortunately nobody&#x27;s gotten around to implementing safe loading natively, but that&#x27;s a python problem, not a yaml 1.2 problem, and ruamel.yaml supports pure-py safe loading that&#x27;s compliant with 1.2 (no integer-interpretation gotchas), which is fine in most cases where yaml is only loaded occasionally, i.e. at start-up, and performance isn&#x27;t critical.<p>Obviously YAML has historical problems, but what&#x27;s better? Using another flawed or even more limited data format, inventing your own which will begin with zero adoption, or simply ensuring your environment&#x2F;app uses yaml 1.2 and best practices?
评论 #34352481 未加载
评论 #34352862 未加载
评论 #34352683 未加载
评论 #34352258 未加载
评论 #34352230 未加载
评论 #34352323 未加载
jjgreen超过 2 年前
What we need is some kind of extensible markup language ...
评论 #34352075 未加载
FpUser超过 2 年前
This is why my own configs are either ini where I know 100% that it would never become complex and take more than few lines or XML for everything else.
thorum超过 2 年前
&gt; The yaml package supports most of YAML 1.2, but preserves some behavior from 1.1 for backwards compatibility. YAML 1.1 bools (yes&#x2F;no, on&#x2F;off) are supported as long as they are being decoded into a typed bool value. Otherwise they behave as a string.<p>Good solution for using YAML with strongly typed languages. No reason to leave type decisions up to a parser. I assume serde does something similar in Rust?
notinfuriated超过 2 年前
To me, the yaml document from hell is a series of yaml documents I helped create that replaced a bunch of database config and hard-coded constants. It helped &#x27;unlock&#x27; the business to create newer forms of products much more quickly and correctly, but it never got moved to an actual database. So at this point, they have some yaml documents that, if expanded to include all references, end up becoming this massive fucking tangled mess.<p>IIRC we never moved it to a database partly because we did not have time to solve for how we actually wanted references to work.<p>The yaml document and code that reads it still work as a way of speeding up the business compared to how things used to be. But that code takes a long time to parse, has probably caused a decent level of confusion for developers who have to mess with it who aren&#x27;t on that team, and has absolutely taken a lot of clock time being parsed for validation checks in unit tests.<p>Still not sure I would have solved that problem differently, aside from perhaps moving the thing to a database immediately after the first phase of working on it.
wg0超过 2 年前
YAML with templating becomes troublesome even more so when these are Django tmeplates. That&#x27;s why I do not prefer ansible for automation. It becomes so much cumbersome at certain point that it is more valuable to jump into a real programming language instead of wresteling with both YAML, Django templating and python.<p>That&#x27;s where I am enthusiastic proponent of pyinfra.
评论 #34353053 未加载
TheFlyingFish超过 2 年前
To me, the #1 reason to use YAML rather than anything else is if you need to embed complex multi-line strings in your document. This is a practical necessity in CI systems: you always end up with at least a little bit of shell scripting to glue things together, and embedding shell scripts into anything other than YAML is an absolute nightmare.<p>Yes, there are too many options for expressing multi-line strings (In the vast majority of cases, I really don&#x27;t care whether it has a trailing newline or not). Yes, there are weird rules that don&#x27;t make sense, like how in &quot;folding&quot; mode a newline followed by two spaces more than the current indentation level <i>doesn&#x27;t</i> get folded. But it&#x27;s still the best option for CI, which is why Github actually ditched HCL in favor of YAML after a while: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20647691" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20647691</a>
vsajip超过 2 年前
The CFG configuration format is a text format for configuration files which is similar to, and a superset of, the JSON format. It&#x27;s not new - it dates from well before its first announcement in 2008 - and has the following aims:<p>* Allow a hierarchical configuration scheme with support for key-value mappings, lists and basic types such as strings, ints, floats, Booleans and date&#x2F;times.<p>* Support cross-references between one part of the configuration and another.<p>* Provide a string interpolation facility to easily build up configuration values from other configuration values.<p>* Provide the ability to compose configurations (using include and merge facilities).<p>* Provide the ability to access real application objects safely, where supported by the platform.<p>* Be completely declarative.<p>It&#x27;s similar to newer formats such as JSON5, HJSON, HOCON and similar but offers a number of features [0] which they don&#x27;t, as indicated by the above list. It&#x27;s not intended to occupy the niche where you find things like Cue, Jsonnet, Dhall and similar.<p>It was just never especially publicised when first implemented for use in Python projects, but it now also has implementations for the JVM, .NET, Go, Rust, D, JavaScript [1], Ruby and Elixir (all BSD-3-Clause licensed) and it would be great to get feedback on the project from the HN community.<p>[0]: <a href="https:&#x2F;&#x2F;docs.red-dove.com&#x2F;cfg&#x2F;intro.html" rel="nofollow">https:&#x2F;&#x2F;docs.red-dove.com&#x2F;cfg&#x2F;intro.html</a> - description of features and comparison with other similar systems<p>[1]: <a href="https:&#x2F;&#x2F;docs.red-dove.com&#x2F;cfg&#x2F;playground.html" rel="nofollow">https:&#x2F;&#x2F;docs.red-dove.com&#x2F;cfg&#x2F;playground.html</a> - uses the JS implementation to create an interactive playground
kabdib超过 2 年前
I will never willingly use YAML on a project ever again. It&#x27;s a bloody disaster. I would actually prefer XML over YAML.
smitty1e超过 2 年前
I like to write Python to manage JSON.<p>Keeping the data and the logic orthogonal (these effin&#x27; Fn::&#x27;s make my eyes bleed) is a win.
theshrike79超过 2 年前
YAML isn&#x27;t the best, but it&#x27;s the least worst.<p>INI doesn&#x27;t let me do hierarchies and is out right out of the gate.<p>I started my career during the &quot;XML ALL THE THINGS&quot; craze and feel physically ill when I need to edit XML. It&#x27;s technically the best, but it can be misused in so many ways[0] that it makes it unviable. XML Schemas, DTD etc make it a breeze to handle programmatically though.<p>JSON might be good, but it doesn&#x27;t have first-class comments and no links or refers. It even kinda has a schema spec.<p>YAML has a ton of edge cases (like in the linked post), but it&#x27;s hierarchical, human editable and machine readable-ish as long as you take the edge cases into use. You can also link and refer elements to reduce repetition.<p>[0] elements with no values, but 20 attributes, too many elements with values, but no attributes, etc etc...
elgertam超过 2 年前
Many commends are (correctly IMO) pointing to JSON as superior to YAML given YAML&#x27;s problems, but these ignore JSON&#x27;s problems due to its lack of semantics. When moving JSON between systems, the JSON parser makes certain assumptions about the JSON document, such as whether the numbers represent integers or single-precision or double-precision floats. This is certainly less obnoxious than &quot;no&quot; being treated as a bool, but it is a problem.<p>A friend of mine created Preserves[0] in part to resolve this problem. I&#x27;d encourage everyone to check it out. To be fair, he&#x27;s also quite pro-Dhall and Nix.<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34354614" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34354614</a>
评论 #34354894 未加载
djrobstep超过 2 年前
Amazing that developers still spend so much time getting bogged down in encoding issues in 2023. Why can&#x27;t we just edit some data structures directly and send send them around seamlessly? It&#x27;s a deeply dysfunctional state of affairs.
评论 #34352303 未加载
nickm12超过 2 年前
For a human-readable, schema-free data representation, I really like Amazon&#x27;s Ion format (disclosure, I&#x27;m an Amazon employee). It is basically JSON + additional types (integers, timestamps, symbols, sexpressions), and support for humane features like trailing commas and comments. It also has a more efficient binary representation. I think it could have been a contender had it been released a decade earlier, but now I think the existing formats are way too entrenched.<p><a href="https:&#x2F;&#x2F;amazon-ion.github.io&#x2F;ion-docs&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;amazon-ion.github.io&#x2F;ion-docs&#x2F;index.html</a>
d4rkp4ttern超过 2 年前
For managing configs of ML experiments (where each experiment can override a base config, and &quot;variant&quot; configs can further override the experiment config, etc), Hydra + Yaml + OmegaConf is really nice.<p><a href="https:&#x2F;&#x2F;hydra.cc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hydra.cc&#x2F;</a><p>I admit I don&#x27;t fully understand all the advanced options in Hydra, but the basic usage is already very useful. A nice guide is here:<p><a href="https:&#x2F;&#x2F;florianwilhelm.info&#x2F;2022&#x2F;01&#x2F;configuration_via_yaml_and_cli_with_hydra&#x2F;" rel="nofollow">https:&#x2F;&#x2F;florianwilhelm.info&#x2F;2022&#x2F;01&#x2F;configuration_via_yaml_a...</a>
jackcviers3超过 2 年前
This is why configurations as code should be written in actual programming languages. Dhall, Nix, and Pulumi are all solutions geared towards configuration but written with fully capable, user-extensible, programming languages.
评论 #34363750 未加载
privacywiki超过 2 年前
Ansible collection writer here, pray for me...
miohtama超过 2 年前
What are the practical modern alternatives for YAML use cased? TOML, others?
评论 #34352224 未加载
评论 #34351974 未加载
评论 #34371709 未加载
评论 #34351894 未加载
评论 #34352228 未加载
评论 #34351811 未加载
groby_b超过 2 年前
Welcome to dynamic typing hell.<p>As long as you ask your configuration language to infer the data type from a piece of text, these are the kinds of edge cases you get to experience. (They vary by language. Less types means less mistakes, and so does less expressive power - but without some form of type hinting, that&#x27;s where you are)<p>Personally, I like YAML for expressive simplicity at the start of a project, and then if it becomes an actual load bearing piece of software (vs a haphazard one off, or an experiment), let&#x27;s add some schema validation &amp; typing.
dmos62超过 2 年前
I was looking for a human-friendly format to store data for a staticly generated website. Stuff like copy, lists, addresses, contact information (so that the rendering logic is kept separate).<p>Landed on NestedText, and apart from it having few implementations, I loved it! <a href="https:&#x2F;&#x2F;nestedtext.org&#x2F;en&#x2F;stable&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nestedtext.org&#x2F;en&#x2F;stable&#x2F;</a><p>I did feel like I missed a more popular alternative, because I can&#x27;t be the only one to want a human-friendly data format.
评论 #34363625 未加载
donatj超过 2 年前
I remember the first time I played with YAML ten-ish years ago. I experimented with converting our configuration file from INI to YAML. It came with an actual noticeable increase to our app startup time in the tens of milliseconds.<p>The YAML evangelist in my company when asked told me I should cache the results… of reading our config file… from the local filesystem. What do I store that cache as? JSON? Just cut out the middle man. Left a really bad taste in my mouth at the time I have yet to get out.
评论 #34352157 未加载
vbezhenar超过 2 年前
The way to solve YAML issues is to invent some widely used yaml pretty printer and shout at everyone not using it.<p>There&#x27;s `yq -P` but it does not implement proper normalization for plenty of mentioned issues which is a shame, really.<p>As I see it, everyone can just start with JSON (as JSON is a subset of YAML) and pretty-print it and use the result whenever it&#x27;s supposed to be used.<p>In other words use safe subset of YAML. May be it&#x27;ll be formalized some day. Yamlite.
评论 #34353845 未加载
nrvn超过 2 年前
it is an old song.<p>JSON (as per spec) is a lightweight data-interchange format.<p>YAML is a &quot;human-friendly data serialization language for all programming languages&quot; and by mere coincidence (it does not look to be by design until version 1.2.2 [0]) JSON is its subset and not vice versa!<p>And YAML is human-friendly in two ways:<p>- it is notoriously &quot;human&quot; in interpreting input, i.e. ignoring the context or misinterpreting others&#x27; words;<p>- it helps read serialized data via indentation-based syntax.<p>The biggest caveat is for whatever reason everyone ignores the key highlights of both JSON and YAML that are &quot;data-interchange format&quot; and &quot;data serialization language&quot;. If I were to interpret these two terms I would rather say they both present great means for heterogenous programs to exchange data with YAML being a fancier brother better suited for human eyes. They were not meant to be used for configuration purposes or what not. But people started using them exactly for this purpose instead of creating a configuration format&#x2F;language that would render into program-readable JSON(if needed).<p>CUE and Dhall are perhaps the first two attempts to create specifically a configuration language with the ability to serialize in yaml&#x2F;json&#x2F;etc.<p>I very much hope using YAML, JSON and even TOML for writing configurations will become an anti-pattern soon and will be replaced by something more suited for this role.<p>[0] <a href="https:&#x2F;&#x2F;yaml.org&#x2F;spec&#x2F;1.2.2&#x2F;#12-yaml-history" rel="nofollow">https:&#x2F;&#x2F;yaml.org&#x2F;spec&#x2F;1.2.2&#x2F;#12-yaml-history</a>
dgan超过 2 年前
If you only need something for internal use, nothing prevents you from using s-expressions, and interpret atoms (number -&gt; uint16_t, dates in &quot;yyyy-mm-dd&quot;) whatever your application feels like... With this lil&#x27; trick all parsing problems are gone. Inferior Format Users will be jealous, and Inferior-Format-Parser-Writers will hate you
rubatuga超过 2 年前
I&#x27;m surprised nobody mentions an alternative called NestedText. It only supports string type, which puts the complexity and responsibility of typing with the application. I think it&#x27;s less prone to parsing errors.<p><a href="https:&#x2F;&#x2F;nestedtext.org&#x2F;en&#x2F;stable&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nestedtext.org&#x2F;en&#x2F;stable&#x2F;</a>
amarshall超过 2 年前
&gt; The key on is common in the wild because it is used in GitHub Actions. I would be really curious to know whether GitHub Actions’ parser looks at &quot;on&quot; or true under the hood.<p>I can say, at least, that using both on: and &#x27;on&#x27; work in GHA. I usually write the latter, makes it simpler to do ad-hoc YAML.parse or whatever on the workflow files.
jgalt212超过 2 年前
Someone needs to write<p>YAML: The Good Parts<p>If you&#x27;re strict about how you use it, it&#x27;s more than workable. And, yes, the Norway problem is insane.
deafpolygon超过 2 年前
I will stick to JSON or TOML if the choice was mine. Hell, I&#x27;d much rather deal with XML than deal with YAML.
OOPMan超过 2 年前
I&#x27;ve ways preferred HOCON to YAML but it never took off :-&#x2F;<p>It&#x27;s a pity, because compared to YAML it&#x27;s a lot simpler from the rules perspective while being flexible enough to do some useful stuff over plain JSON<p>Also, it isn&#x27;t white space dependent, something which annoys me know end with YAML
haileys超过 2 年前
&gt; Templating yaml is a terrible, terrible idea<p>I&#x27;ve had a good time using ytt: <a href="https:&#x2F;&#x2F;carvel.dev&#x2F;ytt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;carvel.dev&#x2F;ytt&#x2F;</a>. It implements language-aware templating, which is IMO the only reasonable way to do it.
评论 #34352514 未加载
bbojan超过 2 年前
I&#x27;ve always hated YAML, and now I&#x27;m glad there&#x27;s a very nicely written article to back me up.<p>I also notice that I have a preference to procedural as opposed to declarative specifications. E.g. I find conditionals and loops in declarative specifications quite bad.
carrja99超过 2 年前
We need to go back to xml. Admit it.
shp0ngle超过 2 年前
What would be good is “strict yaml”, that is, yaml with all those weird cases strictly disallowed?<p>Which would make it backwards compatible, as the cases would just make it invalid “strict yaml”?<p>And I’m thinking it might already exist? I’m surely not the first one to think of that
评论 #34354654 未加载
chrisshroba超过 2 年前
Call me naive or quote xkcd, but whenever I read about the shortcomings of YAML, I daydream about a new standard that&#x27;s mostly a subset of YAML, that looks like this:<p><pre><code> rules: - &quot;All strings must be quoted and are parsed identically to JSON strings&quot; - &quot;true and false are the only boolean values&quot; - &quot;&quot;&quot;multiline strings are allowed&quot;&quot;&quot; - &quot;&quot;&quot;| there can even be special multiline string types to indicate things like &quot;dedent every line and trim the beginning and end lines if empty &quot;&quot;&quot; # Comments are allowed! - Number syntax just like JSON better_than_yaml: true &quot;a number with multiword key&quot;: 1e9 nesting: present: true difficult: false </code></pre> It has the ease of coding of yaml, maps 1:1 with json (so can easily be re-serialized to json or yaml if needed), is familiar to folks who know yaml, and supports comments. And it eliminates ambiguous parses and gotchas, references, tags&#x2F;directives, and other complexities.
contravariant超过 2 年前
If Python is valid option then lisp syntax should also be considered as a viable alternative.<p>Heck the number of times I&#x27;ve seen attempts at creating a lisp in yaml, it is easier to just get it over with and make it a lisp in the first place.
werdnapk超过 2 年前
Almost all of the issues mentioned would be solved by using quoted strings.
bjarneh超过 2 年前
&gt; There were two changes to it in 2005 (the removal of comments, and the addition of scientific notation for numbers)<p>They actually had comments in JSON but removed them in 2005. That is odd and a bit annoying :-)
runeks超过 2 年前
&gt; Leaving strings unquoted can easily lead to unintentional numbers.<p>It seems like this sums up <i>all</i> the issues pointed out by the article. Ie. you’re safe as long as you quote your strings.
deterministic超过 2 年前
Yaml is the complete opposite of what you want: a <i>simple</i> specification language. JSON is the gold standard to measure against. However one step better IMHO is S-expressions.
messe超过 2 年前
Just say Norway to YAML!
rochak超过 2 年前
YAML is the worst format I&#x27;ve had the displeasure of working with. Given how ubiquitous it is, I don&#x27;t see it going away soon, but I am still hopeful.
pnt12超过 2 年前
An unquoted version 3.10 in yaml becomes 3.1. Fun stuff!
deterministic超过 2 年前
I am not a fan of LISP <i>but</i> I use S-expressions all the time for configuration files, dumping data etc. It is simple yet infinitely flexible.
mixmastamyk超过 2 年前
Strict yaml fixes this, I recommend it. Before that I disabled as many of yaml’s features in the library I was using. Look for “safe parsing.”
sampo超过 2 年前
Is there a tool that parses yaml and outputs json, so you could check if the yaml you wrote parses as you intent?
评论 #34351848 未加载
评论 #34352070 未加载
评论 #34365545 未加载
tinglymintyfrsh超过 2 年前
Let&#x27;s not forget: JSON is also valid YAML<p>YAML, OpenSSL, and ASN.1 are what happen when every feature in the world is added.
edent超过 2 年前
This is why I invented KYLI - <a href="https:&#x2F;&#x2F;shkspr.mobi&#x2F;blog&#x2F;2017&#x2F;03&#x2F;kyli-because-it-is-superior-to-json&#x2F;" rel="nofollow">https:&#x2F;&#x2F;shkspr.mobi&#x2F;blog&#x2F;2017&#x2F;03&#x2F;kyli-because-it-is-superior...</a><p>People shouldn&#x27;t be hand-editing these sorts of configuration documents. 21st century tooling would prevent so many of these &quot;foot-guns&quot;.
评论 #34351830 未加载
Kaotique超过 2 年前
While it is indeed total insanity it could easily be avoided by putting quotes around all string values.
jwmoz超过 2 年前
This explains a lot! I just know my docker compose files were always a pain and unintuitive to write.
sigmonsays超过 2 年前
i want *any* configuration format that can rewrite itself(loaded and written to disk again) with two properties we&#x27;ve seem to have lost when we switched away from xml.<p>1. keep ordering of document 2. keep comments of document<p>Does anything like that exist?
lucasfcosta超过 2 年前
I honestly don&#x27;t understand why people still write YAML considering there are alternatives like TOML available.<p>I think attributing semantic value to indentation is a terrible idea. It gets even worse when there is so much visual ambiguity when it comes to defining values and escaping certain character sequences.
revskill超过 2 年前
Secret fact: Hackernews data is stored as a huge YAML file on disk.
rsynnott超过 2 年前
But, of course, _all_ yaml documents are from hell.
synergy20超过 2 年前
so the suggestion is: use toml for configuration, otherwise just stay with json?<p>there is jsonc which is json+comments but I have not used.
slowmovintarget超过 2 年前
&quot;Use the EDN, Luke!&quot;
SuperSandro2000超过 2 年前
I saw NixOS
InsomniacL超过 2 年前
&quot;YAML is Human-readable&quot;<p>&quot;You must count whitespace for nesting&quot;<p>Pick one or the other, but not both.
评论 #34353575 未加载
adenozine超过 2 年前
Every day we stray farther from the light of XML.<p>At this point, it’s just plain ridiculous.
tgv超过 2 年前
TLDR: unexpected conversions to other types in YAML 1.1.<p>A larger JSON document is hell to write and read, though.
评论 #34351853 未加载
评论 #34351758 未加载