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

51–60 of 68 posts

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

#51

Post by simonrepp »

fernly wrote: post #36
mamcx wrote: post #17

What 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..

This! As the introduction doc coyly says, > so as a user we usually just concern ourselves with editing the values and a friendly developer takes care of specifying the names for us. :) The friendly developer gets the job of conveying -- somehow -- that values for landline: and mobile: have to be valid tel#s (but must they have the country prefix?) while "hire date:" must be in the form yyyy mm dd only... and also ge…

Conveying what types to enter is not an eno-specific problem, as a user without schema or code access you don't know which types a blank YAML/TOML file expects either!

Asides the absolutely valid meta solutions (e.g. in-file comments, clear key naming, documentation) there is an additional way this is approached in eno: If you use the type loaders provided by the API (say 'my_var = document.url('website')'), and properly expose errors to the user, the user will get a localized (!) error message in his language, like "'website' must be a valid url (e.g. https://eno-lang.org/)".

In the long run we can have community packages for any number of important locally unique types (loaders are just simple functions, so they can be easily authored), so at some point you likely don't have to write any one-off validation code, and neither the error messages or their localizations, you just pull it in as dependencies.

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

#52

Post by dathinab »

I just read the benchmarks and was surprised at how slow the toml parsers are, I mean it's syntax is simpler to parse than YAML (assuming spec v1.2) but they where still slower...

So I guess there is simply no high performance toml parser implementations?? (in the tested languages, which don't include rust)

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

#53

Post by shakna »

CJefferson wrote: post #49
shakna wrote: post #45

Earlier quoted context omitted.

Python 2 is EOL in just over a year. Why would anyone write for a piece of software that will be completely unsupported in 18 months?

Because, it is installed on Macs, as I said. I don't want to have to teach people how to install python 3, when they already have python 2, which is fine. Also, redhat had promised support for a while yet, and I expect spoke to keep it working until they replace with Python 3 (or remove python altogether?)

> Because, it is installed on Macs, as I said.

Apple also only supports very ancient set of GNU tools. That doesn't mean that in the majority of cases it is a wise choice to lock yourself to those same outdated tools - especially on a platform that hasn't guaranteed the presence of said tools.

> I don't want to have to teach people how to install python 3, when they already have python 2, which is fine.

I haven't directly addressed anything to do with your personal choices. However, this thread started with the quote:

> no python 2 support means no python support

Which frankly, isn't true. Python 2 is about to be EOL'd.

> Also, redhat had promised support for a while yet

I wouldn't depend upon it being long-term however. RHEL8 drops Python 2, and RHEL 7.5 deprecated it. [0]

[0] https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N...

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

#54

Post by simonrepp »

dathinab wrote: post #52

I just read the benchmarks and was surprised at how slow the toml parsers are, I mean it's syntax is simpler to parse than YAML (assuming spec v1.2) but they where still slower... So I guess there is simply no high performance toml parser implementations?? (in the tested languages, which don't include rust)

From what I saw, I think for at least a few parsers this might be the case because they are built on generated parser code, and it's just easy to run into unfavorable bits and pieces in the output that way, which can drag down performance completely although 95% of the parser are just fine. Technically there's no reasons why toml parsers shouldn't be just as fast or faster as yaml or even eno. :) In any case I'd be happy if the benchmarks stir up some movement and maybe kick off some high performance toml parser intiative, toml is an awesome format and also 0.5.0 was just officially released so there's a good reason to update the parsers now anyway. :)

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

#55

Post by simonrepp »

jajag wrote: post #13

I 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?

One of the design conderations was and is that the format is very strict (and that way predictable), but at the same time as helpful as possible in identifying, communicating and resolving issues.

To that end all error messages that can occur are handwritten, fully localized and shared across all eno libraries (see https://github.com/eno-lang/eno-locales/blob/master/specific...) and the API implicitly handles them for you when you write programs that consume eno.

So basically eno does no magic fallbacks of any sort when faults occur, but it is candid and friendly about it when it happens. :)

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

#56

Post by simonrepp »

mamcx wrote: post #17

What 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..

Regarding types check out https://eno-lang.org/javascript/#loaders - basically eno allows arbitrary types on the language level and provides loaders for all primitive types and currently also a small set of non-primitive types through the libraries. The extent of loaders provided out of the box might grow, likely also externalized into companion packages like https://github.com/eno-lang/enojs-exploaders/, which currently serves as experimentation ground for this.

The core might in fact be reimplemented in C or Rust and used across implementations through native bindings, although only a small portion of the actual parsing core can actually be outsourced like that, so it will depend what the actual benchmarks say then, there's also cost associated with passing around the data through bindings, the devil's in the details there unfortunately. :)

The editor in the introspection demo is atom, the introspection is based on the excellent automcomplete boilerplate at https://codersblock.com/blog/creating-an-autocomplete-plug-i... paired with a few lines that utilize https://eno-lang.org/javascript/#Section-lookup to determine the exact context for the autocomplete suggestions. Glad you like, thanks for your interest!

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

#57

Post by simonrepp »

mitchtbaum wrote: post #19

first 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)

Hey, first off thanks! :)

1a) because faster was only one aspect, it also needed to be easier, even more pressingly that in fact. 1b) see answer by other poster (thanks!) 2) Not whitespace sensitive, no way to enter wrong types through syntax mistakes, hardly any learning curve for users because there is so little syntax to memorize, fully localized, hand written parser and validation errors (provided on the library side) ... and so on, check out the website for more, it's all there! ;) Thanks!

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

#58

Post by simonrepp »

edoceo wrote: post #27

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.

Sure!

Cultural research = notoriously underfunded, so although they have and rely on a relational database that holds their data (previously Postgres) the cost and effort associated with maintaining and extending the system is pretty high.

With the new setup the thousands of eno files represent both the place of storage and the interface to edit the data, so by that we eliminated the development effort to provide and maintain a full web frontend to the database, and the effort to just maintain the actively deployed technology somewhere and keep it at least patched for security reasons.

All that remains now technology wise is an Atom plugin that is locally installed on each client at the institute and takes care of validating, provides relational autocomplete helpers as demonstrated in [4] and offers a few hooks to kick off local builds for multiple deployment targets and deploy them to live as well.

Hope this clarifies things! :)

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

#59

Post by simonrepp »

petershinners wrote: post #24

It looks like there is no support for writing data to this formatting. My inner hope was that there was a format I could parse, modify, and write again preserving as much comments and formatting as is reasonable. I looked at the Python implementation but did not see that type of functionality. Am I wrong?

ruamel.yaml in python does that to a certain degree from what I've read, you might want to check it out if yaml is ok for your usecase! (https://yaml.readthedocs.io/en/latest/)

I've given this some thought as well, and given that the eno libraries hold their own representation of data in memory this might actually be plausible to implement in some way. Still I fear this will turn out to be a hard, hard problem (as eno is not even generically serializable by design), so that's why I haven't explored it further. So for the moment I can only say - Maybe in the near future sometime, check back every once in a while! :)

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

#60

Post by simonrepp »

amann11 wrote: post #37

Is there support for dictionaries as list items / nested dictionaries?

Yes through sections! See https://eno-lang.org/introduction/.

You can nest as deeply as you want and multiple sections on the same level automatically turn into a list of sections. For just a list of flat dictionaries you can also use fieldsets, see https://eno-lang.org/advanced/. :)

Post reply on HN