[deleted]
Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
11–20 of 68 posts
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#12Do you remember when people were writing plain C parsers first? Pepperidge farm remembers!
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#13I like this, but I'm wondering how strict the format is. It seems like a potentially useful format for capturing data from a non- or semi-technical user base, but then some degree of fault tolerance in the entered data would probably be desirable. Was this (or should it be?) one of the design goals?
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#14What I was looking for on the website and think is more than implementing a parser in another language is schema support. That is, you should provide something like XSD for XML, JSONSchema for JSON, TOLS for TOML. Why? There is a need (see above enumeration) to declaratively specify how an Eno file should look like. I do not want validation to creep into my code, like you do with `document.string('author', required:…
As someone who has worked has written parsers & worker with generated parsers, to add to what OP has said about performance, from my experience there is a lot of noise that comes from a generated parser, and interacting with the code/output is quite unpleasant.
Also you have to decide on checking in garbage generated code into your source or adding a build step so you don’t check the code in (which is less trivial for certain languages/stacks).
Unless I’m making an MVP or a prototype I would write the parser. It’s not as hard as it sounds
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#15Related as a better config language (but universal, not for a use case like this) is dhall (non-turing complete, type-safe, remote imports).
https://github.com/dhall-lang/dhall-lang
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#16This is amazing. We really needed an alternative to YAML, and this seems great.
Have you seen strictyaml?
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#17What about types?
All parse to string? If not, hopefully please add date/datetime support (better as ISO) and decimal.
---- > More languages?
How about make the core on Rust and the rest use it?
BTW: What your use for the introspection? What editor is that? I like the auto-complete stuff..
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#18Why would I use a field set instead of a section? They seem functionally identical, is it meant to be a semantic decision?
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#19first off, I agree that file-based content management is the way to go. thank you for working to make better tools for it.
> we wanted something 1) faster and 2) easier
1) a) why didn't you write a new library using the same spec? b) do you have speed tests to show your libraries are better than existing ones?
2) how is this spec easier? (like a basic rundown)
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#20first off, I agree that file-based content management is the way to go. thank you for working to make better tools for it. > we wanted something 1) faster and 2) easier 1) a) why didn't you write a new library using the same spec? b) do you have speed tests to show your libraries are better than existing ones? 2) how is this spec easier? (like a basic rundown)
> b) do you have speed tests to show your libraries are better than existing ones?
The OP linked to their benchmarks in [3]: https://github.com/eno-lang/benchmarks/