Yeah, wide-reaching support is critical for whatever will replace YAML. So here's hoping someone with polyglot programming chops decides to tackle something like HCL because it does look pretty nice.
Well, that looks quite nice from a configuration language perspective. Sadly I can't find much pleasant in the Rust ecosystem for using it which limits my ability to experiment with it greatly.
While it still makes me sad, YAML does have wide reaching implementation support :(
I haven't found a formal language definition yet, other than "compatible with json" is there something obvious I'm missing? On the face of it, it seems to have some niceness for humans at least.
YAML is certainly not an information interchange language, I agree. JSON fits the bill quite nicely for that IMO.
I've never seen HCL before (assuming you mean 'Hashicorp Configuration Language') so I'll take a look at it.
What would you prefer as a structured data format which isn't entirely awful for humans to interact with? The condition I place on it is that as a human I'm not made sad. json, xml, toml, all make me sad. (YAML makes me _less_ sad, but not happy).
Sadly in the 'real world' it tends to mean "Can write a web UI, but can also work on the API service which it talks to, and probably write the SQL schema that service uses" It makes me very sad.
To me, a full stack developer can at least *understand* and *modify* anything from VHDL/Verilog through bootloaders, kernels, low level OS code, middleware, services, UI, servers, etc. Also some ability to read/adjust schematics and hardware layout.
To a webdev, who knows?
This is why I spend a bit longer on my AoC solutions than many (I never get on the leaderboard really) but I try and write code I *can* come back to and understand later.