Kinda worthless rant, but I'm tired of reconsidering configuration file markup language every couple of years, and please remind me: why TOML isn't perfect?
Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
31–40 of 68 posts
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#32Kinda worthless rant, but I'm tired of reconsidering configuration file markup language every couple of years, and please remind me: why TOML isn't perfect?
If you already believe TOML is perfect, why do you reconsider configuration file markup languages every couple of years?
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#33Kinda worthless rant, but I'm tired of reconsidering configuration file markup language every couple of years, and please remind me: why TOML isn't perfect?
TOML/YAML:
You could read a truncated TOML file and not realize it.
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#34Kinda worthless rant, but I'm tired of reconsidering configuration file markup language every couple of years, and please remind me: why TOML isn't perfect?
If you already believe TOML is perfect, why do you reconsider configuration file markup languages every couple of years?
[deleted]
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#35Can 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.
Programming languages are more powerful than SQL, so it might make sense for "research" stuff.
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#36What 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 gets the friendly job of writing one-off, locally unique validation code for these fields and hacking them into the parser.
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#37Is there support for dictionaries as list items / nested dictionaries?
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#38Honestly, putting a pair of parentheses in all of these plain text format, you get back lisp.
Greenspun's tenth rule rules!
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#39no python 2 support means no python support
That was true several years ago, much less so today
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#40no python 2 support means no python support
Python 2's end of life is in 1 year, 4 months. https://pythonclock.org/