←back to thread

257 points pmig | 2 comments | | HN request time: 0s | source
Show context
epolanski ◴[] No.43096608[source]
Very ignorant about Go, is dependency injection not a thing there?

E.g. I like declaring interfaces in other languages that model some service (e.g. the database), focus on the API, and then be able to provide different implementations that may use completely different technologies behind them.

I know that some people don't see the point, but I'll make an example. At my primary client the database layer is abstracted and provided at runtime (or compile time, depends) with the repository pattern. How's that useful? Developers can use a filesystem-based database when working, and don't need to setup docker images that provide databases, anything they do is saved on their machine's filesystem. E2Es can run against an in-memory database, which makes it very simple to parallelise tons of different tests as there are no race conditions. And yes, the saved formats are the same and can be imported in the other databases, which is very useful for debugging (you can dump the prod database data you need and run it against your implementation).

There's many other situations where this is useful, one of the core products I work on interfaces with different printing systems. Developers don't have printers at home and my clients have different printing networks. Again, abstracting all of it through DI makes for a very sane and scalable experience.

I don't see how can this be achieved as easily without DI. It's a very nice tool for many use cases.

replies(6): >>43096619 #>>43096645 #>>43096738 #>>43096799 #>>43096998 #>>43097708 #
gt0 ◴[] No.43096645[source]
DI exists in Go, but it's not ubiquitous like it is in the C# or Java worlds.

Last time I used Go, I used "wire" for DI and was pretty happy with it.

replies(1): >>43096758 #
cflewis ◴[] No.43096758[source]
I worked on Wire right at the beginning, happy to answer any questions about it.
replies(2): >>43097112 #>>43097625 #
1. gowk ◴[] No.43097625[source]
Given that the development of Wire seems to have slowed down, do you still recommend using Wire for dependency injection in Go projects? How has your perspective on its design philosophy evolved over time?
replies(1): >>43098049 #
2. cflewis ◴[] No.43098049[source]
Can’t comment on the slowdown, I left the team a long time ago.

The goal at the time I thought was very sound: it was a massive PITA that Go programs that ran on cloud servers (of which I would hazard most of them do) were not Write Once Run Anywhere. It was all the same stuff, right? A blob store. A SQL backend. Etc etc. What we wanted was to say “you write a Go program, here run it on GCP. Then Azure. Why not AliBaba if you’re in China”.

What I am no longer convinced of today is that anyone is really looking for those greased rails because it’s _so much more complicated_ to run on cloud servers than I envisioned. Surely it was going to get more simple? But it didn’t. Networking, authorization, scaling, Kubernetes. The list goes on and on.

A fully uneducated guess is that Wire does what people who come to it want it to do, but it’s not attracting new users because the use cases are more constrained than envisaged.