4 ms·
The simplicity of the language means no gigantic class hierarchies. Theres are fewer ways to do something. Since engineers spend most of their time reading and
by mxschumacher 7y ago
The simplicity of the language means no gigantic class hierarchies. Theres are fewer ways to do something.
Since engineers spend most of their time reading and debugging, readability and low abstractions facilitate collaboration: it should be relatively straightforward to jump into any Go codebase.
People often laud the relative ease of picking up the language. They're productive quickly, that's not by accident.
- zerr 7y agoIt doesn't restrict gigantic hierarchies per se, just the compiler won't help you there.
- throwaway894345 7y agoThere isn’t inheritance, so there are no hierarchies in the problematic sense.
- apta 7y agoYou get problems like this, which you don't get in traditional OO languages: https://github.com/golang/go/issues/16474 https://github.com/golang/go/issues/16474
- throwaway894345 7y agoWhat are you talking about? You could do exactly this in Java or C# or Python or Ruby or JS or etc. Not sure what ”traditional” languages you’re talking about, but this is just reflection and downcasting. It’s a bad idea, but it’s unrelated to OOP.
- apta 7y agoYou can't cast a type to an arbitrary interface and hope that it implements the method(s) you want to call in Java or C#.
- throwaway894345 7y agoThey aren’t “hoping it implements an interface”, they use reflection to determine whether or not the type implements the interface. This is pretty much the same thing in Java or C# with reflection and downcasting, but it’s a bad idea in both languages.
- pjmlp 7y agoSure there is, spaghetti interface implementations, even types that happen to implement interfaces that they didn't intend to, with methods that happen to match the signature, having completely different semantics.
- throwaway894345 7y agoThose aren’t hierarchies as I understand them, nor do I understand those to be real problems (I’m sure someone has been bitten by one of those but only by the law of averages).
- pjmlp 7y agoOOP is not Java.
- throwaway894345 7y agoI don’t see how that’s relevant.
- apta 7y agoThe fewer ways just means that now you have to jump through hoops to fight against the language, ending up with more complicated code bases (and this has been observed in practice). > People often laud the relative ease of picking up the language. That's not a great metric to measure the effectiveness of a language. Furthermore, there are still gotchas that people have to learn to be aware of, and patterns of how the language does things that need to be learned. Again, the same can be said of Java/C#.
- dgb23 7y agoI agree but there is a significant tradeoff. You are forced to use lower level expressions, meaning you reinvent algorithms and more importantly their names. For example splitting a collection with a predicate in FP jargon would be „partition“. The function name is descriptive and universal (to those who know it). In Go it is another for loop, which is more verbose, can be implemented in different ways and doesn’t show intent until read and understood. This rather small example shows how Go programming (read: reading/writing code) doesn’t scale as well with better understanding and experience, as programming in more expressive languages. Note that I‘m not saying that this is absolutely good/bad. There are obvious merits to Go‘s approach.