Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

After a quick look I have a lot of questions

1) Unlike YAML or JSON this doesn't parse into a simple array structure, but a library dependent object hierarchy?

2) Is the API of the libraries also part of the language spec?

3) Can I assume that document.lookup() will be available as document->lookup() in the PHP library?

4) What about programming language specifics that may differ between languages? Will the PHP objects implement the Iterable interface? Or the ArrayAccess interface? (There are probably similar but slightly different concepts in other languages).

5) There is eno.parse(), but is there some kind of reverse mechanism to create a new Eno document? Like document.addList([...]).addSection('hey', 2) or something.

It seems bizarre that you wouldn't create a C version of this library. If you create a C version, everyone can write bindings and consume it from their favorite language. I think maybe you can do that with Rust code, but it's typical to write the canonical version in C.

Your benchmarks are flawed, as they only compare between different implementations using the same language. If you really care about performance, it seems bizarre that you'd use PHP or Ruby.

(You can with Rust, yes)

Can you talk about why "" We migrated a big relational research database to a file-based solution""?

I'm curious how modern DBs failed you here, more details of the problem space please.

no python 2 support means no python support