Hacker News new | ask | show | jobs
by rossmohax 2196 days ago
YAML is the new XML. Monstrous configurations used by some magic runtime to glue pieces together.

Dependency injection frameworks were there already and decided against it at the end. I wish CI, data pipelines, config management, IaC tools and all other modern users of YAML-fits-everything approach learned from the past.

What we need is an ease of creating mini languages, but apparently it is not something industry/academia is aiming at, so this skill in not existent among common engineers, which often come up with ideas of new products.

4 comments

HashiCorp is doing fine with config files in hcl or json. What’s your specific complain here? To me it seems your mini languages would anyway compile into something very similar to those yaml files. It’s all graph nodes in the end. But I do agree a language would be nicer when it comes to testing
>Dependency injection frameworks were there already and decided against it at the end.

How did dependency injection frameworks solve this problem then?

By declaring dependencies in code (usually with annotations or decorators)
What do you do when you want to choose the implementation for dependencies and optionally configure them at runtime?

I think that's why most of the popular dependency injection frameworks I see support configuration through XML or JSON.

Firstly, you barely ever do.

Secondly, unless you're selling compiled software for others to configure, there really is no difference between config in config files and config in code, except that the former does not let you build such meaningful and useful abstractions. You're presumably delivering it all into production via CI/CD anyway, so what difference editing a config file vs. some actual source code, besides the lack of real type safety and IDE assistance?

Pulumi have figured this out.

(And I suspect that if your end users need to configure your software's use of Spring's Dependency Injection in XML config then you are probably doing it wrong.)

What exactly has Pulumi figured out?

FWIU, their path is not the right one for DevOps.

Dhall and Cue have the correct starting philosophy, i.e Turing incomplete

Then you also do that in code? I don't see how that would differ. If your container doesn't support that, you can always just make a Factory for it.
Language implementation has never been easier with Earley parsing.

Your users still have to learn your new language. That’s the part designers are trying to avoid.

https://curlang.org is amazing, I see devops going from YamHell to Cuetopia
I believe the muscle memory from typing the name of an amazing http client overtook the URL you meant to type:

https://cuelang.org/