MAmaxboone·Sep 12, 2025Submission
Google's Wire is no longer maintained
2 points · Open discussiongoogle
wire
Go2018–2025
google / wire · Archived
wire
Compile-time Dependency Injection for Go
13Distinct people
13Mentions
0Explicit recommenders
14.4KGitHub stars
What to know before exploring
What it is
Compile-time Dependency Injection for Go
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year13 dated mentions
Observed mentions: 2018-12-02 14:44:35 UTC to 2025-09-12 21:55:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
13 sourcesWe've adopted Google Wire for some projects at JustWatch, and it's been a game changer. It's surprisingly under the radar, but it helped us eliminate messy shutdown logic in Kubernetes. Wire forces clean dependency injection, so now everything shuts down in order instead... well who knows :-D
https://go.dev/blog/wire
https://github.com/google/wire
In Graceful Shutdown in Go: Practical Patternscode generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice.
But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc
In Borgo is a statically typed language that compiles to Go`fx` is mostly just Dependency Injection in Go which has been a thing in Java forever.
I'm curious though, when do you reach for `fx` in a non-industrial project and when do you not? I still use the same patterns of separating out the implementation from the interface but I've been wiring in the dependencies by hand. I'm curious if folks reach for `fx` immediately or if it's something that requires thought to add. There's also Google's wire library [1] that does similar stuff but takes a compile time approach so it's a little easier to reason about if struct initialization screws up due to weird implicit things.
I still wire dependencies up by hand, but I'm curious what others do.
[1]: https://github.com/google/wire/tree/main
In The case of a leaky goroutineAs they didn't seem to link to it https://github.com/google/wire
In Google’s Wire: Automated Dependency Injection in GoI believe Go supports DI via Wire (https://github.com/google/wire).
In Generics can make your Go code slowerI've used this framework. The exceptions being deferred until runtime were really frustrating.
If you really want to use DI in golang, for some reason, wire[1] at least still gives you type safety and compile-time failures.
1. https://github.com/google/wire
In Dependency injection in Go with Uber-go/fxFor a slightly different take on this problem, check out Wire (https://github.com/google/wire).
In Dependency injection in Go with Uber-go/fxThat thing that's largely not used? Sure, some person who signed Google's onerous employment contract wrote that. Look what other stuff those people are pushing https://cloud.google.com/open-cloud/ and see how it's all "enterprise solutions" while the community adoption is at 694 projects importing wire: https://pkg.go.dev/github.com/google/wire?tab=importedby
In Jodd – The Unbearable Lightness of JavaTake a look at the major DI frameworks for Go, Wire [0] and FX [1]. They just plumb the gaps between methods that return types and methods that want them. Although technically they work for concrete types, 99% of the time it's going to be an interface, so that you can substitute a mock for testing.
Prior to DI frameworks we used global variables, often initialized in a package's init() method.
>The desire to do this reflects a misunderstanding of interfaces.
Generally you have a few layers: gRPC/HTTP/Kafka handler, business logic, and database or external service access. Layers are unit tested individually against mocks of the layers below. Because you're going to inject a mock, you can't depend on a concrete type, so you depend on an interface. Often when you're developing you want to know what the concrete implementation of a lower laye
Read the rest
r does, so it's useful to have "go-to-definition" see through the interface declaration to its implementations.
I think the implicit satisfaction of interfaces is very cool and I wish I had it in every language. I wouldn't give it up just to simplify the IDE's job. But the IDE having this functionality does matter.
[0] https://github.com/google/wire
[1] https://github.com/uber-go/fx
> and the HTTP package should not be polluted with assumptions about what (if any) data is being passed.
I'm not talking about the HTTP package itself. In Java and C# you do something along the lines of
// Java
CompletableFuture<PagedResult<Contract>> getContracts(...);
CompletableFuture<PagedResult<Client>> getClients...(...);
CompletableFuture<PagedResult<Book>> getBooks...(...);
// C#
JsonSerializer.Deserialize<PagedResult<Contract>>(responseBody);
JsonSerializer.Deserialize<PagedResult<Client>>(responseBody);
JsonSerializer.Deserialize<PagedResult<Book>>(responseBody);
And that's basically it. With Go you end up having fifteen identical PagedResult types for every single type that can be returned from the API because you can't parametrize anything:
// Go
type ContractsResult struct {
Result []*entitie
Read the rest
s.Contract
NextPageToken string
}
type ClientsResult struct {
Result []*entities.Client
NextPageToken string
}
type BooksResult struct {
Result []*entities.Book
NextPageToken string
}
> Or they use code generators, which is also pointed out in the article.
Code generators are just bandaid for glaring holes in the language. Worse still, I don't know if you can even specify code generating tools in your go.mod. For example, wire's installation instructions say "you need to install wire globally and have it on your $GOPATH" [1] So your go build will just fail mysteriously until you have all the necessary tools installed.
> Of course, anything more advanced would be greatly helped with generics
That... that is exactly what I'm talking about.
> Option types to avoid nil, Either types to replace the value/error tuples
Indeed. I forgot about those :) Yup, that would be a great use case for generics.
[1] https://github.com/google/wire
Wire: Compile-Time Dependency Injection for Go
1 points · Open discussionGoogle Wire: Compile-time dependency injection for Go
2 points · Open discussion