Martin Tournoij

There's a linked article discussing the shortcomings of YAML, as well: https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html

Reading the two screeds together, though, I think the author has ignored one key idea of both JSON and YAML as formats: their use-cases are complementary, and the "problems" with each of these two formats only arises when you're using one for the use-case best suited to the other.

YAML's use-case is for human-written configuration. That's why it has so many weird ways to write things: to allow humans to write some data down in a way that works best to communicate said data to other humans, in a way that machines can coincidentally read. (See also: AppleScript.)

And that's also why YAML is "so powerful that it's basically inherently insecure." You shouldn't be executing untrusted YAML any more than you should be executing an untrusted bash script. YAML is a language for the deploying sysadmins of a piece of software to configure said software with; it's not a language for the tenants of a system to communicate their needs to the system with.

JSON's use-case is for building machine data generators and parsers in a distributed system (like the web) where it is very important that the data be easily introspected by humans, and that humans will also be able to modify or otherwise "poke at" said data, in flight, using simple text-based tools. But the intention isn't that humans will ever author JSON "at scale." JSON is like HTTP/1.0: it's…

>The terms "free software" and "open source" have a specific meaning in the software ecosystem. The former is defined by the Free Software Definition and the latter by the Open Source Definition, respectively published by the FSF and OSI. These definitions both require that the software is available for commercial use without restriction, among other things.

Problem: The OSI did not coin the term 'open source'. OSI partisans claim that Christine Peterson coined the term at a strategy meeting in Palo Alto on 3 February 1998. However, the term and the concept was well known prior to that. Martin Tournoij does a decent enough job of collecting prior citations [1] that go all the way back to 1990. All the OSI did was take an existing philosophy, scribble some new restrictions in crayon, and called it Open Source(tm)(c)(pat. pending).

Honestly, though, I do love it when this comes up. It gives me the opportunity to irk new guys telling them that Lyle Ball, head of public relations at Caldera, has an earlier citation than the OSI in the form of a press-release announcing Caldera OpenDOS[2][3]. :D

[1] https://www.arp242.net/open-source.html

[2] http://www.xent.com/FoRK-archive/fall96/0269.html

[3] http://ftp.uni-bayreuth.de/pc/caldera/OpenDOS.701/license.txt

https://news.ycombinator.com/item?id=26504021

Looks great! "Zapier for DevOps" would convey it a lot faster. It didn't click for me until I got to that part. I'm excited to try it out!

A couple things:

1) Please, please support some other config file other than just YAML. Even JSON would be an improvement, since you wouldn't have to change your config reader library. YAML has been a miserable nightmare to use in other tools like Open API Spec. I'm not alone in my YAML hate, either[1][2][3][4].

Implicit typing and semantic whitespace in a data file is insane. At least in Python, you're not unlikely to get an error if your whitespace is off. In a config file, you might just end up with dangerous/confusing behavior.

2) I'm surprised you used Relay, which is already used by Facebook. I don't think Facebook is going to care that much, but it's going to be really hard to Google this library.

1. https://dev.to/jessekphillips/stop-using-yaml-3kec

2. https://hitchdev.com/strictyaml/why/implicit-typing-removed/

3. https://devopsdays.org/events/2019-stockholm/program/philipp-krenn

4. https://www.arp242.net/yaml-config.html

> No, open source means the same thing it's always meant since the term was first coined. See the Open Source Initiative's Open Source Definition: https://opensource.org/osd.

Problem: The OSI did not coin the term 'open source'. OSI partisans claim that Christine Peterson coined the term at a strategy meeting in Palo Alto on 3 February 1998. However, the term and the concept was well known prior to that. Martin Tournoij does a decent enough job of collecting prior citations [1] that go all the way back to 1990. All the OSI did was take an existing philosophy, scribble some new restrictions in crayon, and called it Open Source(tm)(c)(pat. pending).

Honestly, though, I do love it when this comes up. It gives me the opportunity to irk new guys telling them that Lyle Ball, head of public relations at Caldera, has an earlier citation than the OSI in the form of a press-release announcing Caldera OpenDOS[2][3]. :D

[1] https://www.arp242.net/open-source.html

[2] http://www.xent.com/FoRK-archive/fall96/0269.html

[3] http://ftp.uni-bayreuth.de/pc/caldera/OpenDOS.701/license.txt

SQLite is awesome, but it's still an order of magnitude more complex than JSON. If it wants to be the one file format to rule them all, we're going to need high quality and heavily used implementations in most languages.

Adding C sqlite to a golang project adds a significant hit to build times and cross-compilation/static linking complexity[0]. When I looked into the native Go implementations of sqlite I came away with the feeling it wasn't worth the tradeoffs compared to using the C version, but now I still have to deal with the issues above.

I haven't looked deeply into how sqlite works, but my instincts tell me the reason we don't have high quality implementations in every language is because it's actually too complex to treat as a protocol.

I would love to see something fill the void between plain text and sqlite.

[0]: https://www.arp242.net/static-go.html

> The “open source” label was created at a strategy session held on February 3rd, 1998

You can see the term gaining popularity prior to 3 Feb 1998, and there are references to for example BSD being 'open source' as far back as 1990.

https://books.google.com/ngrams/graph?content=open+source%2Copen-source%2Cfree+software&case_insensitive=on&year_start=1970&year_end=2008&corpus=15&smoothing=3&share=&direct_url=t4%3B%2Copen%20source%3B%2Cc0%3B%2Cs0%3B%3BOpen%20Source%3B%2Cc0%3B%3Bopen%20source%3B%2Cc0%3B%3BOpen%20source%3B%2Cc0%3B.t4%3B%2Copen%20-%20source%3B%2Cc0%3B%2Cs0%3B%3Bopen%20-%20source%3B%2Cc0%3B%3BOpen%20-%20source%3B%2Cc0%3B%3BOpen%20-%20Source%3B%2Cc0%3B.t4%3B%2Cfree%20software%3B%2Cc0%3B%2Cs0%3B%3Bfree%20software%3B%2Cc0%3B%3BFree%20Software%3B%2Cc0%3B%3BFree%20software%3B%2Cc0%3B%3BFREE%20SOFTWARE%3B%2Cc0

Via https://www.arp242.net/open-source.html.