Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: