7 ms·

This is basically "Use DI, and move towards SOLID" Well, yeah! Those are great principles in any language - I find it concerning (and maybe indicative of somet

This is basically "Use DI, and move towards SOLID" Well, yeah! Those are great principles in any language - I find it concerning (and maybe indicative of something) that the Go community has voted this up. These are fundamental requirements to building testable, scalable systems in teams. Having global variables has been bad practice for what, 20 years? One of the first lines in Javascript, the Good Parts (closest book handy) is: JavaScript is built on some very good ideas and a few very bad ones. ... The bad ideas include a programming >model based on global variables.

kasey_junk 9y ago
this article falls into a particular genre "sensible advice that is either so internalized in other languages or the language itself prevents the pathology so why would you write that." It's a winning combo because you can recycle old and simple ideas for a whole new context. [edit] felt bad because rereading this it implies the author has bad intentions. Don't mean that. Just mean it's cute to watch the golang community learn Java.
- yumaikas 9y ago
  In some ways, I consider Go to be a bit of a redo of the early ideas of Java, but with a bit more focus on tooling, and a stronger aim towards simplicity. And Go's standard library authors have the benefit of seeing how Java's early days played out. I do enjoy that Go gives a bit more obvious control over memory layout than Java did, and I enjoy using it as a small projects language. I've never used it in full anger/production, so I haven't seen the worst of it. One funny thing about Guice(mentioned elsewhere): I've heard more than one Googler say that dislike the framework quite a bit, due to how heavily it can be abused. One bit of advice that seems to have gone either missing in Java/JVM, or common knowledge, is the idea that only main/binary packages should have config options via flags/env vars. Many, many JVM libraries do not follow that convention, and I've had to hunt down a log4j XML file for Spark in order to turn down the logging levels before. Would much rather have that be controlled via a flag.
  - chubot 9y ago
    Yes, flags vs. config files in Unix are a classic example of dependency injection vs. side effects, but at the process level rather than the programming language level. At Google pretty much all server configuration is done with flags. Binaries can and do have thousands of flags. And I view that as a much better solution than a config file that is searched for. The idea is that modular units like processes and functions don't "search for configuration", they just accept parameters, and led the higher level application configure them. Then the code becomes very straightforward to read and debug.
- deleted 9y ago
  [deleted]
- weberc2 9y ago
  Go has had syntax support for DI since day 1 (map, slice, struct literal syntax). JaVA has to choose between frameworks and boilerplate.
  - JBReefer 9y ago
    I'm not sure what you're describing, but it's not Dependency Injection. People are downvoting you for ignorance, which is unfair. Here is what we are discussing, it does not relate to value object declaration syntax. https://en.m.wikipedia.org/wiki/Dependency_injection https://en.m.wikipedia.org/wiki/Dependency_injection
    - weberc2 9y ago
      You use the syntax to inject the dependencies. I'm not ignorant about DI, I was probably downvoted for being unclear. I could also imagine some people down voting because they don't understand that DI is a general concept and not a framework or class of frameworks (at least this confusion seems common).
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 ago
  Explicit 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 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 ago
      Go has struct, slice, and map literal syntax.
      - kasey_junk 9y ago
        You 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 ago
        Java 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.
weberc2 9y ago
I think many Go converts (myself included) came to the language because it's type system (composition, structural subtyping), syntax, standard library, and conventions all work together towards DI/SOLID. I interpret these upvotes as more of a "Yes, we get this right" than a "Wow, what a great idea!" In particular, Go programs are much more likely in my experience to be SOLID/DI than JS, Python, Java, C#, etc, mostly because the language was designed to support it.

kasey_junk 9y ago

this article falls into a particular genre "sensible advice that is either so internalized in other languages or the language itself prevents the pathology so why would you write that." It's a winning combo because you can recycle old and simple ideas for a whole new context. [edit] felt bad because rereading this it implies the author has bad intentions. Don't mean that. Just mean it's cute to watch the golang community learn Java.

yumaikas 9y ago
In some ways, I consider Go to be a bit of a redo of the early ideas of Java, but with a bit more focus on tooling, and a stronger aim towards simplicity. And Go's standard library authors have the benefit of seeing how Java's early days played out. I do enjoy that Go gives a bit more obvious control over memory layout than Java did, and I enjoy using it as a small projects language. I've never used it in full anger/production, so I haven't seen the worst of it. One funny thing about Guice(mentioned elsewhere): I've heard more than one Googler say that dislike the framework quite a bit, due to how heavily it can be abused. One bit of advice that seems to have gone either missing in Java/JVM, or common knowledge, is the idea that only main/binary packages should have config options via flags/env vars. Many, many JVM libraries do not follow that convention, and I've had to hunt down a log4j XML file for Spark in order to turn down the logging levels before. Would much rather have that be controlled via a flag.
- chubot 9y ago
  Yes, flags vs. config files in Unix are a classic example of dependency injection vs. side effects, but at the process level rather than the programming language level. At Google pretty much all server configuration is done with flags. Binaries can and do have thousands of flags. And I view that as a much better solution than a config file that is searched for. The idea is that modular units like processes and functions don't "search for configuration", they just accept parameters, and led the higher level application configure them. Then the code becomes very straightforward to read and debug.
deleted 9y ago
[deleted]
weberc2 9y ago
Go has had syntax support for DI since day 1 (map, slice, struct literal syntax). JaVA has to choose between frameworks and boilerplate.
- JBReefer 9y ago
  I'm not sure what you're describing, but it's not Dependency Injection. People are downvoting you for ignorance, which is unfair. Here is what we are discussing, it does not relate to value object declaration syntax. https://en.m.wikipedia.org/wiki/Dependency_injection https://en.m.wikipedia.org/wiki/Dependency_injection
  - weberc2 9y ago
    You use the syntax to inject the dependencies. I'm not ignorant about DI, I was probably downvoted for being unclear. I could also imagine some people down voting because they don't understand that DI is a general concept and not a framework or class of frameworks (at least this confusion seems common).

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 ago
Explicit 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 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 ago
    Go has struct, slice, and map literal syntax.
    - kasey_junk 9y ago
      You 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 ago
        Java 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.

weberc2 9y ago

I think many Go converts (myself included) came to the language because it's type system (composition, structural subtyping), syntax, standard library, and conventions all work together towards DI/SOLID. I interpret these upvotes as more of a "Yes, we get this right" than a "Wow, what a great idea!" In particular, Go programs are much more likely in my experience to be SOLID/DI than JS, Python, Java, C#, etc, mostly because the language was designed to support it.