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

I'd like to see a language with baked in support for dependency injections, so that my functions can take two types of parameters: its "real" parameters, which it needs to perform its function, and "dependencies", that are passed implicitly by the runtime.

Basically, a formalization of Dagger/Guice into a language.



You can do dependency injection with dynamic binding. See another post in this thread: https://news.ycombinator.com/item?id=32085346

An approach to do it statically is with implicit parameters. Scala has them, for example.


Monadic functional languages have native support for dependency injection and typeclasses/interfaces provide interoperability and easy mocking or alternative implementations with type-checking / propagation of which dependency they are using. (As to avoid mismatching between mocks and a real implementation for example)

https://itnext.io/hmock-first-rate-mocks-in-haskell-e59d7c3b...


This article is just about mocks and doesn't really touch on dependency injection at all, and Haskell simply doesn't have the mechanisms to supply the kind of implicit passing that useful DI requires.


Sounds like you are taking about ReaderT, which is a common way of implicitly passing more data to functions. There are many other ways, though.


`Reader` and `ReaderT` are not implicit at all, they still need to pass parameters explicitly.

What other ways do you have in mind?

I am not aware of any Haskell functionality or compiler flag that enables implicit parameter passing, like Java, Kotlin, and Rust allow.



People have written drafts of a design for this for Rust. Calling it capabilities.


As a part of the language standard / standard library, or as a third party crate? I'm confused how this would work, as as far as I'm aware, making this a language-level feature would require significant changes to the ethos of the language.

There are some examples, e.g. the Bevy ECS doing more or less dependency injection for you (and ensuring against things like aliased mutable references), which is pretty neat.



Fascinating. Not sure what my opinion is of it yet.

Reminds me of implicit parameters in Scala - https://docs.scala-lang.org/tour/implicit-parameters.html

Edit: I think I like it. It doesn't solve dependency injection like e.g. Guice but the examples given, e.g. providing implementations for traits defined in external crates that take arbitrary state, is compelling.




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

Search: