simonrepp

I'll attempt to list some major points: - TOML keys are alphanumeric, in eno they allow the full unicode range - In eno there are no inline syntax constructs like in TOML, this is simpler although sometimes more verbose - TOML has fixed types and type syntax rules on the language level, eno has arbitrary application-defined types - TOML is designed for completely generic de/serialization (through fixed types), eno relies on domain-specific serialization

There are also (maybe even more) important paradigmatic differences concerning how the parser APIs differ, and also need to differ, given the different typing approach in TOML vs. eno, but I'll limit this to the language points for brevity here. :)

Generally speaking - the higher the volume of content/configuration/data there is in a given application or the more it is relevant that the application is also accessible and easily usable for users without a technical background or the more your data and types are application specific and possibly exotic, the more I would recommend eno.

On the other hand, the more generic your data (especially the more it requires generic serialization), the more it is shared by myriads of different applications, the more it is handled by a very technical audience, the more I would recommend TOML.

Yay thanks for the detailed input!

If there is demand or initiative for a portable schema solution I'll gladly support it! The native architecture in the eno libraries is programmatic because that does have its own powerful merits which are employed to the fullest in the API design, like always there's not one best choice, and the 'validation creeping into code' can be turned around into 'external schema definition creeping out of line with code' just as well. ;) Do you have some concrete usecase in mind or planned where we could explore how a portable schema solution could look like for eno? Drafting things from various real life use cases has worked great for eno so far, so that's the route I would love to go here too if we follow that track!

Custom parser implementation is easier to answer: By now I've iterated through dozens of custom parser designs for eno in multiple languages, and I'm pretty much confident that generated parsers will not stand a chance of being faster, they after all do the same thing as I do, only I can't really hand-optimize what they produce afterwards. :) You can study the benchmarks I linked to under [3], there are some generated TOML parsers included with rather disappointing performance to put it mildly, and as it stands there's not much that's faster than the eno parsers in YAML/TOML land anyway, so I have low incentive to experiment in that domain currently. :) Long term goal is to (optionally) integrate (generated or custom) C (respectively Rust) parser cores through native bindings as well, so that will bring up this question again then for sure.

That's fantastic to hear! Do let me know via email or github etc. if you run into any issues, I'm eager to gather more insights from other people's usecases and work on improvements where needed!

Thanks michael! <3

Thanks for the kind words, much appreciated!