Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 68 posts

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

#1

Post by simonrepp »

eno [1] - A modern plaintext language w/ libraries [2] for JavaScript, Python, Ruby & soon more!

We migrated a big relational research database to a file-based solution - requirements were:

- Super fast and easy editability for users

- Highest performance for parsing/validating >10K documents on every user change.

Our trials with YAML/TOML showed us that we wanted something both faster [3][4] and easier [4], something tailored for file-based content management ... and after months of research & development it's now publicly available (under MIT license) for everyone!

Last but not least I also want to mention eno's document introspection capabilities - with a few lines of code you can build intelligent relational suggestion UIs as shown in [4] below.

[1] https://eno-lang.org/

[2] https://eno-lang.org/libraries/

[3] https://github.com/eno-lang/benchmarks/

[4] https://eno-lang.org/resources/introspection.mp4

PS. Your input for the Roadmap is highly welcome - what do you think should be in the next releases? More languages? (If so, which? Currently in progress: Rust/PHP, Currently planned: Go/Java) Additional IDE/editor support? (Currently supported: Atom/VSCode/Sublime) Or something else entirely? :) Looking forward to your feedback!

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

#4

Post by mschwanzer »

The level of sophistication you got this to over the last few months is truly impressive. Supporting several languages and IDE/editors from the start takes serious dedication for one person. Kudos! Looking forward to using it for my next database-less project.

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

#5

Post by simonrepp »

mschwanzer wrote: post #4

The level of sophistication you got this to over the last few months is truly impressive. Supporting several languages and IDE/editors from the start takes serious dedication for one person. Kudos! Looking forward to using it for my next database-less project.

Thanks michael! <3

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

#6

Post by topspin »

I am working on a spectrum diagram rendering system and have been thinking hard about what syntax I should select for source documents. I'm going to give eno a hard look and the existence of JavaScript parser is not the least of my reasons. Thank you.

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

#7

Post by simonrepp »

topspin wrote: post #6

I am working on a spectrum diagram rendering system and have been thinking hard about what syntax I should select for source documents. I'm going to give eno a hard look and the existence of JavaScript parser is not the least of my reasons. Thank you.

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!

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

#8

Post by lorenzleutgeb »

What 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: true)`. This just scares the hell out of me. Say you want to parse some Eno file with different languages, you also end up replicating validation, which mains you end up maintaining it, or rather not maintaining it... Apply leverage by moving validation into your parser.

Another thing is that it appears you are implementing the parsers by hand instead of using a parser generator that consumes a grammar for Eno. What is your reasoning behind this? Is it performance? Did you benchmark using generated parsers (maybe wrapped in a nice API)?

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

#9

Post by simonrepp »

lorenzleutgeb wrote: post #8

What 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:…

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.

Post reply on HN