6 ms·
It's relevant because the Go community needs to rebuild all this, and is re-discovering that they can learn from existing patterns that many claimed were irrele
by Groxx 9y ago
It's relevant because the Go community needs to rebuild all this, and is re-discovering that they can learn from existing patterns that many claimed were irrelevant because Go was so simple and so different.
Plus the lack of runtime control means you are essentially forced to do explicit DI, or you have an untestable mess. Hopefully the DI libs will catch up to e.g. Java's sophistication within a year or two.
- weberc2 9y agoExplicit DI is far better than a DI framework is your languages supports a sane syntax for composing structures. Java is a boilerplate-laden language and so it profits from a DI framework whereas Go doesn't. Building a DI framework isn't hard (contrary to your post, Go has the necessary runtime support), simply no one is interested. :)
- openasocket 9y agoWhat do you mean by "sane syntax for composing structures"? I use both Go and Java at work, and when it comes to constructing complex objects they both seem to have the same amount of boilerplate.
- weberc2 9y agoGo has struct, slice, and map literal syntax.
- kasey_junk 9y agoYou know that most languages support those things right? And they have virtually nothing to do with DI? If you are going to make an argument for more natural support for DI in go than other "strongly" typed languages it starts and ends with structural typing.
- weberc2 9y agoJava doesn't. C# doesn't. C++ doesn't (or maybe it does as of the last few years). And the languages which have them (or something passably close) don't use DI frameworks (Python, JS, etc). They might exist in those languages, but they're fare from common. The point is that DI frameworks reduce boilerplate. Go head less boilerplate than, say Java.
- kasey_junk 9y agoAre you suggesting that the fact that the language has special syntax for initializing a few types means it has better support for dependency injection? I don't even understand the basic premise of that argument. It seems nonsensical.
- weberc2 9y agoI wouldn't put it that way; it simply means the ROI for a framework is lower, and in Go's case, it's zero or less. It makes perfect sense because Go's syntax servers the same main purpose as a DI framework--to reduce initialization boilerplate.
- ninkendo 9y agoC++ has had it since C++11 with uniform initialization syntax. You can even create literals for your own classes, which you can't in Go.
- weberc2 9y agoThanks for clarifying
- openasocket 9y agoHow does having struct literals help with DI? Can you give an example?
- weberc2 9y ago
- deleted 9y ago[deleted]
- Groxx 9y agooooh no, people are interested. Go DI frameworks are appearing rapidly. Simple ones are indeed simple (and often all you need, which is great), but that's nowhere near all there is to the field.
- echlebek 9y agoCan you explain how a library for dependency injection could improve a Go standard library like net/http, io, encoding/json, or database/sql?
- JBReefer 9y agoIt wouldn't. It is for when you want to swap out that library, or test business logic using that library beyond simple unit tests. DI is also great for creating modular code you compose, instead of monoliths. It encourages the use of interfaces and information hiding - you should look into it, it's a very powerful technique. Instead of asking how it would improve an arbitrary library, ask yourself "how screwed am I if 100% of the API surface for this library changes tomorrow?" Dependency injection would help you out of that faster that rewriting everything.