My bad. I read the article but I must have skimmed past the section about DPAN being randomized because I don't remember seeing it. The majority of my attention went the last part about personal details where I thought it was pretty obvious. Short attention span.
Uber also made something called fx, which is fantastic.
You don't have to use it, but when you do, it helps ensure that you organize your code in a way that becomes very easily testable. It enforces a modular approach to composing together golang services.
Being more easily testable helps prevent bugs, like these leaky goroutines.
`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.
I co-founded Java @ Apache, so my background is Java and DI was the first thing I was looking for when I started down the golang path. I tried out a bunch of different DI options for golang and settled on fx. fx is actually more than just DI, it is a whole framework for starting and stopping "services" as well.
I realized quickly it wasn't absolutely necessary to use it since most people just make a package in golang, in order to get the separation they need. But when I started using it more and more, I noticed that taking advantage of the DI features of fx, also ensured that I wrote code that had clear separation of concerns.
In golang, it is too easy to just cross package include `new` things you need right in the function, instead of passing it in as an argument. This of course, makes it much harder to write tests for since you can't mock what you need easily.
The binary I built was distributed across tens of thousands of servers in multiple data centers, and had to run perfectly on every release as it took a lot of time/effort to even do updates. This meant comprehensive testing before deployment, so I wanted to optimize my unit/integration tests as much as possible.
I'm not sure it would be necessary for just simple api endpoint microservices, but for a complicated application binary that needs perfect testing, I can't imagine writing golang code without it. The benefits far outweigh the negatives.
Yeah when I've written Go at scale we've used fx for similar reasons. But for smaller projects I go back-and-forth. Fx makes it quick and easy to start using DI and avoid the repetitive hand initialization and injection, but for smaller codebases it's also much easier to reason about. FWIW I haven't used wire before as if I'm at a scale smaller than fx I'm just wiring in structs by hand.
I still wire things up by hand: pass concrete parameters, use defer foo.Close(), use context.Context for signaling close. It’s super obvious how stuff works. In a 200k line code base, there are maybe 2 components where I haven’t been able to simplify the shutdown sequence to my satisfaction, but I doubt a framework would add clarity there.
I found fx to be good for fast iteration, think quickly shipping startup code. You can just sorta spaghetti wire everything together and it's mostly okay. Though one can ask why in that situation you aren't using a dynamic language which is a good question.
