8 ms·
You have a problem and you need a configuration language, so you pick YAML. Now you have two problems. Take a leaf out of Rust's book and use something simple
by sanity31415 6y ago
You have a problem and you need a configuration language, so you pick YAML. Now you have two problems.
Take a leaf out of Rust's book and use something simple and sane like TOML, YAML is a mess.
See: https://github.com/cblp/yaml-sucks https://github.com/cblp/yaml-sucks
Otherwise this looks like a great project, please don't ruin it with YAML.
- freedomben 6y agoYou can find absurd behavior during corner cases in nearly any non-trivial language. YAML is a great language when you need to represent objects in something universal and human readable/writable. Not perfect of course, but TOML's limitations can turn stuff into a monstrosity with it's limitations. Ansible inventory files come to mind here.
- eptcyka 6y agoOne can find absurd behavior in corner cases of any non-trivial language, but one can find absurd behavior in YAML without even looking for it.
- whimsicalism 6y agoSuch as? All these cases with no and norwegian or whatever but I haven't run into major problems and use it frequently. e: And, AFAIK, I believe the latest YAML 1.2 spec (from 2009) has addressed these issues.
- metrix 6y agoI use it frequently too, but there's some terrible edge cases: https://stackoverflow.com/questions/53648244/specifying-the-string-value-yes-in-a-yaml-property https://stackoverflow.com/questions/53648244/specifying-the-...
- whimsicalism 6y ago? I don't think these are issues with Yaml 1.2, the spec since 2009.
- eptcyka 6y agoWhat about `thing: 1.0` and `thing: 1.0.0`? Parser implementations have also been buggy. The ruby one in particular being a source of RCE's. Of course, these are implementation issues, but surely a simpler specofication would be easier to implement. And the current specification is anything but simple, clocking 84 pages in the PDF flavour.
- sanity31415 6y agoThe "no"/"norwegian" thing is emblematic of very sloppy thinking in YAML's design, and it's far from the only example. It's possible to avoid these pitfalls - like people do with PHP - but why burden users with that in a new project when better options have been available for years? They obviously like Rust, why not just follow their lead with TOML?
- whimsicalism 6y agoThat "feature" regarding "no" hasn't even been present in the YAML spec since 2009.
- renewiltord 6y agoThanks for being clear about this and repeating it. I didn’t know. I think I will only use YAML 1.2 as configuration language.
- coldtea 6y agoThe NO alone should give you pause... It's a language that coerces basic strings...
- ralmidani 6y agoNon-rhetorical questions: why not use the language itself so people can leverage features like autocomplete, type-checking, linting, and intuitive error handling in an IDE? Is there anything about Rust that makes it impractical for representing config/dependencies/etc?
- anon_tor_12345 6y agohow do you imagine this working? should the binaries for this ship a rust compiler?
- ralmidani 6y agoYou could, for example, compile AOT to a JSON file and build everything deterministically from there. Tell devs to not edit that JSON directly. I believe NPM and Yarn do something similar.
- anon_tor_12345 6y agoi have no idea what you're saying >compile AOT to a JSON file and build everything deterministically from there you want the dev that develops zellij to AOT compile all settings (that they set using rust as you imagine) to a JSON file that is then... what by end users? inspected but not edited? how would settings change then?
- goldsteinq 6y agoYep. Rust is a compiled language with monomorphized generics. It's slow to compile, and also you'll need to carry rustc everywhere. rustc is huge.
- jhgb 6y agoOr, one could embed Chez Scheme, the compiler of which is like 800 kB in size and compiles stuff very quickly.
- 5y ago
- bit-rot 6y agoThis feels like a bit of a bikeshed. There are problems with many configuration languages. I don't see anything related to yaml on their issue tracker.
- whimsicalism 6y agoHN on ShowHN posts is almost always a series of bikesheds
- sanity31415 6y ago> bikeshedding > Futile investment of time and energy in discussion of marginal technical issues I don't see how the choice of configuration file format is a marginal technical issue. It makes a big difference to the ergonomics of a tool. It's one of the things I like most about Rust over my main programming language Kotlin. Rust has Cargo which uses TOML, which is nice and simple. It's so much more pleasant to use than Koltin's Gradle.
- mixmastamyk 6y agoSearch up "strict yaml" it is a pretty good alternative to both.
- earthboundkid 6y agoThere are a million good alternatives. The question is why would you deliberately choose YAML for a new project when we now have a lot of real world experience about how it sucks. It's like deliberately choosing SOAP for a new API…
- earthboundkid 6y ago> It's fashionable to hate XML because it was used in a lot of places it was a bad fit in the 00s, but at least it's a pretty good document language. > YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit? https://twitter.com/carlmjohnson/status/1372224080749993988 https://twitter.com/carlmjohnson/status/1372224080749993988
- forgotpwd16 6y agoThe human readable part is a bit subjective. I find YAML more human readable than TOML.
- earthboundkid 5y agoReadable, maybe? I mean as long as the YAML is correctly quoted, sure, it looks fine. But that's a big if. But writeable, hell no. I have been writing YAML for years and still have no idea how the quoting works, and not for lacking of looking it up in the past.
- j1elo 6y agoI never got this stance; JSON sucks for config files, because as a user, if there is anywhere that I need and am more thankful for comments, is in a configuration file. And TOML is maybe a good substitute for INI formats, but it doesn't really support nested data like JSON would, so suggesting to use TOML instead of JSON is misleading except for the simplest and most basic needs. If replacing JSON is the objective, I'd very much rather recommend HJSON [1] than TOML. [1]: https://hjson.github.io/faq.html https://hjson.github.io/faq.html
- hctaw 6y agoI think the biggest problem with YAML is not YAML itself but what people use it for. It's very flexible and readable for smaller files (much more than TOML - which is awful for hierarchical data). A bigger problem is that so many things are using config files that should be proper DSLs or libraries, but no one wants to maintain a library (or create RCE as a service by accident) and no one wants to write a parser/interpreter. Most of the "YAML sucks" issues would go away if we stopped treating LowCode as something desirable (we do actually need to write code sometimes, as it happens) and if we had better sandboxing/parser generators along with less animosity towards DSLs.
- nsm 6y agoThere is now a good parser/interpreter already written for a proper configuration DSL in Rust - https://github.com/facebookexperimental/starlark-rust https://github.com/facebookexperimental/starlark-rust
- vinceguidry 6y agoMy beef with YAML is that configuration should be flat, not hierarchical. There should be at very most one layer of nesting, to facilitate categories. INI files are fine. People do unholy things with it like nest bash scripts in it that should never be done. Text files should never have more than one syntax needing parsing. It's bad enough, say, embedding SQL into some python. But doing that with YAML is just the worst. You should be able to use regexes to deal with non-code text files. JSON, YAML, the whole motley crew require parsing. Don't get me started on JSON log files.
- nsm 6y agoIf your Rust program needs a more complicated configuration (conditionals, access to APIs and so on), also look at Facebook's Starlark parser and tooling[1]. Starlark is a subset of Python used by Bazel, Buck and a few other projects. [1]: https://github.com/facebookexperimental/starlark-rust https://github.com/facebookexperimental/starlark-rust
- intricatedetail 6y agoI get the yaml hate - I used to do that too. But as I worked more with it I can say I have not had any problems. I think toml feels actually more complex
- 2bluesc 6y agoOne of the most painful things about using tumxp is modifying the YAML to make it useful. Was hopeful this would leverage TOML as it's built using rust.
- donio 6y agoYAML sucks but so does TOML, especially when it comes to nested data structures like the layout.yaml shown on the front page. There are no good configuration languages in existence and there never will be. We have rejected Lisp/sexp so now we must suffer endlessly.
- nine_k 6y agoI would say that Dhall is fine, just from a parallel universe. JSON is close to sexps, but it sucks when comments are not allowed.
- nathell 6y agoWhich is why EDN is so much better for config.
- rch 6y agoTake a look at HOCON (Human-Optimized Config Object Notation) https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md
- KajMagnus 6y agoYes! I logged in just to mention HOCON, then I noticed you have mentioned it already :- ) So, the project you linked to is Java / Scala: https://github.com/lightbend/config https://github.com/lightbend/config And there're also (basic? complete?) HOCON parsers in Javascript and Rust — I investigated this a while ago, because I want to use HOCON everywhere in my projects: https://docs.rs/hocon/0.5.1/hocon/ https://docs.rs/hocon/0.5.1/hocon/ (Rust) https://www.google.com/search?q=hocon+javascript https://www.google.com/search?q=hocon+javascript (Js, a few different) The Rust version: > This implementation goal is to be as permissive as possible, returning a valid document with all errors wrapped in `Hocon::BadValue` when a correct value cannot be computed How nice :- ) (it seems to me)
- IshKebab 6y agoI agree that TOML sucks for nested structures. JSON5 is probably the best option at the moment. https://json5.org/ https://json5.org/ * Instantly obvious what the structure is (unlike YAML or TOML). * Everyone knows JSON already. This just makes it a bit nicer. * No noob security mistakes or type confusion caused by underquoting like YAML.
- zestyping 6y agoYAML is the worst choice. Please use something else!
- akavel 6y agoOr, to avoid sooner or later falling into Greenspun's Tenth Rule, just go immediately to Lua, which actually evolved out of a configuration language (https://www.lua.org/history.html https://www.lua.org/history.html), so it has syntax & features that are quite friendly for writing configs.
- rendaw 6y agoI'd never heard of Greenspun's tenth but that's good to know! I had a personal theory that all program configuration interfaces eventually become programming languages (poorly) and maybe this fits in there.
- dimitrios1 6y ago> I had a personal theory that all program configuration interfaces eventually become programming languages (poorly) and maybe this fits in there. This is absolutely true. Another recent high profile example I can think of is HCL with terraform.
- akavel 6y agoI actually just stumbled upon an article where someone went through HCL and finally landed at Lua: http://dnaeon.github.io/choosing-lua-as-the-ddl-and-config-language/ http://dnaeon.github.io/choosing-lua-as-the-ddl-and-config-l...
- lenkite 6y agoLua tables are great for nested configurations like layouts.
- fit2rule 6y agoLua is the best.
- bschwindHN 6y agoFor hierarchical data I've found JSON5 to be much more enjoyable to work with than YAML or TOML.
- petters 6y agoYes, TOML is great for some things but not hierarchical data.
- smrtinsert 6y agosame comment, different config format, year after year after year...
- keymone 6y agoYAML is the worst, kill it with fire. Whether TOML is decent alternative is debatable though, i'd prefer EDN.
- infogulch 6y agoConfiguration language seems to be a hot topic at HN today, as every day. "Don't use X, use Y instead" has spawned this thread with everybody putting in their favorite configuration language in the hat for consideration. Lets list the ones that have appeared so far: YAML, TOML, Lisp, Dhall, JSON, EDN, JSON5, HOCON, Lua, HCL, XML, HJSON, Starlark, strict yaml About a third of which I'd never heard of. And because I can't help myself (the dogpile is so enticing!), I have to say that the one that I'm most interested in is: Dhall.
- jupp0r 6y agoIf you don't like it, just generate the YAML from something else: https://github.com/dbohdan/remarshal https://github.com/dbohdan/remarshal
- outworlder 6y ago> You have a problem and you need a configuration language, so you pick YAML. Now you have two problems. So much debate could have been avoided if we stuck with S-Expressions from the beginning.
- baq 5y agoi submit dhall as a good alternative https://dhall-lang.org/ https://dhall-lang.org/
- wtetzner 5y agoI think YAML works fine if you're mapping it into typed data structures, because if you know the target type, you can coerce where possible and fail with an error message otherwise. It can potentially cause a mess if you're using it in a dynamic language, and aren't explicitly coercing/validating the input.