3 ms·
What 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
by openasocket 9y ago
What 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 agoThe primary purpose of a DI framework is to alleviate boilerplate by offering a simpler mechanism for describing compositions than provided by the language. If a language already has a handy initialization/composition syntax, you don't get anything from a DI framework. Different frameworks have different bells and whistles, so this is a general point.
- openasocket 9y agoAgain, I find for constructing things Golang is no more or less boilerplate-y than Java. Can you give an explicit example (like, with code) where Golang's struct literal syntax allows you to construct objects with less boilerplate than Java?
- weberc2 9y agoSure. Anything with hash map or list literals (heaven forbid a list of hash maps!), off the top of my head. I'm not near a computer or I'd type out the example.
- openasocket 9y agoWell Java does have array literals. They don't have hash map literals, but I really don't use map literals very often in Go except for constants. And you can make a HashMap in Java in the same number of lines as Golang (though not for an array of hash maps). I really don't see that as a killer feature.
- weberc2 9y agoArrays aren't equivalent to slices in Go. Map literals are nice for things like the driver pattern (a map of strings to some interface type; the user specifies which driver implementation should be used to handle some input). It's not about the number of lines, it's about having a declarative initialization syntax. In other words, it's about the number of expressions. This isn't a killer feature, it jjust means Go requires less boilerplate when doing explicit DI, so the ROI offered by a DI framework is low. If you don't agree that initialization in Go requires less boilerplate, maybe you should be asking yourself what you gain from your DI framework?
- deleted 9y ago[deleted]