Why do so many people complain about generics, yet nobody complains about a lack of inheritance ?

You can't swing a dead cat in hacker news, or reddit for the most part without hitting someone with a complaint about a lack of templated types in Go. Yet by comparison, almost nobody complains about Go's decision to not support subtyping and inheritance. Why is this so ? Why are so many happy with the statement "Go doesn't support subtyping, do it another way", yet so few can accept the identical statement "Go doesn't support generic programming, do it another way" ? <hr/>**评论：** djherbis: <pre>One possible explanation might be that you can get what you want out of sub classing and inheritance from Embedding in Go, which is pretty straightforward. Whereas solving generics problems effectively in Go requires thinking about them in a distinctly different way (like the sort package).</pre>ericanderton: <pre>I think this is it. Also, Interfaces are satisfied implicitly, rather than explicitly. This covers much of the territory that is classically covered by inheritance. Instead of saying that a Dog is an Animal (inheritance), you simply ask the compiler: Does this Animal look like a Dog?</pre>danredux: <pre>Duck typing.</pre>quiI: <pre>Inheritance is often seen as a bit of a broken feature actually. (see: Prefer composition over inheritance <a href="http://en.wikipedia.org/wiki/Composition_over_inheritance">http://en.wikipedia.org/wiki/Composition_over_inheritance</a>). Please note "prefer", sometimes it does have it's place. Compared to generics which are very very useful. </pre>jerf: <pre>I think this is the key. Even before Go 1.0 came out, inheritance was on its way out. Even by Go 1.0, syntactically privileging composition instead of inheritance was a solid, tested idea than a crazy one. By contrast, people feel that generics are a solid, tested idea that Go for some reason does not include. (I split the difference on this myself... I agree that the idea isn't as solid as many people think it is and the vast bulk of implementations have serious issues that people are just so used to working around that they don't see anymore, but, on the flip side, I do sometimes really miss efficient custom containers.) Go will probably help inheritance on its way out the door, but it didn't create the direction inheritance was already headed.</pre>Feribg: <pre>Embedded types and the way interfaces work is a good enough solution for me in most cases. But the lack of generics is gruelling, just introduces way too much boilerplate and code repetition and goes against the purpose of Go being an expressive language. To be honest that's probably the biggest minus for me personally and it got to the point where i started moving away from the language. Hopefully in future versions the team comes up with a solution, but using code generators as part of your build process and telling me that that's perfectly fine is not OKyy. After all the purposes of choosing Go (or any other language) would be that you want nice, clean, maintainable and expressive code. But if you can't express something as common as "I want a list of type" in a type safe manner, you are bound to end up with something that's unpleasant to read and work with, hence the complaints. So to answer your question: The lack of sub typing is addressable by the tools Go provides, the lack of generics is not. The other thing i was really unhappy with despite the recent decision that vendoring is the way to go. I just think this is moving is backwards and not forwards. There are so many good dependency management utilities that could've been used as an example. While i get the technical difficulty of implementing generics, i can't find a good enough explanation of why vendoring is the recommended approach to dep management.</pre>natefinch: <pre>I'm curious to know what you need generics for so often that it's turning you away from the language. Certainly there are some domains that use a lot of algorithm-style programming that could be annoying without generics... but I find that most of the domains that Go targets (command line applications, server applications, and web servers) aren't actually that heavy on the algorithms.</pre>Feribg: <pre>Well not having generics makes any type of collections library non trivial to implement and that in it of itself is a huge issue. By non trivial I mean everything is an interface and then you cast and pray. This doesn't only hold to collections, but to anything that you want to abstract in a major way, but since collections are so widely used Im just throwing them as an example. And you are right maybe its not that big of a pain if you are willing to sacrifice type safety and you expect people to write decent code (and we all know how that ends up). But this notion of code repetition just comes up over and over again in the language and I couldn't swallow it. It seems that the community's response for the limitations of the type system is just use interface{}, aka bypass it altogether. I guess its a trade off, so if you want a simple language you will be bound to write boilerplate stuff. So personally I prefer something that allows me a bit more expressiveness and abstraction.</pre>natefinch: <pre>The community's response is not to use interface{}, generally. It's to simply not use generic containers other than a map or slice, or build on top of those. The Juju codebase (which I work on) (<a href="https://github.com/juju/juju">https://github.com/juju/juju</a>) is over 300k lines of code, and we have like 1100 uses of interface{}, mostly for printing or marhsalling/unmarshalling. Certainly not as a stand-in for generics in all but a very small number of cases. The most code repetition I've experienced is stupid for loops, like what would be .Contains() method in other languages.... but that code is so trivial, I don't even consider it to be a problem. So my question is, what kind of containers were you creating that you really wanted to be generic? In my experience, most of the time, people write a generic container and then end up only using it with one type (or a few tightly related types, but they could make it one type if they tried).</pre>skinney: <pre><blockquote> The most code repetition I've experienced is stupid for loops, like what would be .Contains() method in other languages.... but that code is so trivial, I don't even consider it to be a problem. </blockquote> It starts trivial, but can grow ugly quick, especially if you want the for-loop to be performed concurrently. Something like pmap in Go would be nice, but cannot currently be done in a type safe way.</pre>Feribg: <pre><blockquote> So my question is, what kind of containers were you creating that you really wanted to be generic? In my experience, most of the time, people write a generic container and then end up only using it with one type (or a few tightly related types, but they could make it one type if they tried). </blockquote> Please have a look below at my answer to Dave Cheney, I also address this point that you made. </pre>davecheney: <pre>Can you give concrete examples of collection types you need that could not be satisfied by maps and slices?</pre>skinney: <pre>OrderedMap, OrderedSlice, Set, OrderedSet, Trees, Tries, and immutable versions of these.</pre>: <pre>[deleted]</pre>theonlycosmonaut: <pre>Could one only provide an immutable API for a type that's internally mutable? I don't know Go well enough to know if that'd be enforcible.</pre>skinney: <pre>You create a new data structure that only has an immutable api. While you could access the struct fields directly, that would be a pain in the case of a HAMT.</pre>skelterjohn: <pre>OrderedSlice? Slices are naturally ordered. OrderedSet makes no sense. Ordered maps, sets that aren't map[T]bool, trees and tries would certainly be nice. The easiest way to support immutable datastructures is to not mute your datastructures.</pre>danredux: <pre>Sets should be map[T]struct{}, by the way.</pre>skelterjohn: <pre>I like map[T]bool because then I can check "if m[v] { ... }" and it will be false if the item was not added.</pre>skinney: <pre><blockquote> OrderedSlice? Slices are naturally ordered. </blockquote> I thought that if I appended something to a slice, it was appended at the end and not in order? <blockquote> OrderedSet makes no sense. </blockquote> OrderedSet makes perfect sense if you want to iterate the contents in, say, alphabetic order. I do this from time to time in Clojure(Script). <blockquote> The easiest way to support immutable datastructures is to not mute your datastructures. </blockquote> And we know how that works in a real project. The best way I think is to have a separate type for it. Preferable something that is efficient to create a new version of, like a persistent HAMT.</pre>skelterjohn: <pre><blockquote> <blockquote> OrderedSlice? Slices are naturally ordered. I thought that if I appended something to a slice, it was appended at the end and not in order? </blockquote> </blockquote> Then you mean SortedSlice. <blockquote> <blockquote> OrderedSet makes no sense. OrderedSet makes perfect sense if you want to iterate the contents in, say, alphabetic order. I do this from time to time in Clojure(Script). </blockquote> </blockquote> OrderedSet makes no sense because a set is by definition an unordered construct. Otherwise you mean some sort of sorted unique-valued list.</pre>Feribg: <pre><blockquote> Can you give concrete examples of collection types you need that could not be satisfied by maps and slices? So my question is, what kind of containers were you creating that you really wanted to be generic? In my experience, most of the time, people write a generic container and then end up only using it with one type (or a few tightly related types, but they could make it one type if they tried). </blockquote> Skinny already mentioned a few, but the list can go on and on really. You might want immutable ones, synchronized ones, different types of buffers and queues etc. And I get the argument that I can implement my OrderedSet for my custom type that I need and it would work. The problem is that everyone in their repository will have a slightly different implementation of OrderedSet that works with their slightly different types and thats where the mess begins. Instead of having a unified Go.collections where you get expected behaviour across projects, you end up with custom wrappers and custom collections implementations all over the place and Im sure you agree this cannot be a good thing in the long run if you want to have maintainable code. A typical example of what I mean is: <a href="https://golang.org/src/container/list/list.go" rel="nofollow">https://golang.org/src/container/list/list.go</a> So list is a list of Element, and Element is essentially a wrapper of interface{}. So let's say someone else creates MyListImpl, now doesn't take Element, but it takes MyElement. That's my main problem with portability because every library author will have their own Collections impl. What is inside of Element. For example a List<Element>, right now can mean a List of 1 Element with Value of type A, 1 Element with Value of type B and C. That's not great. Those are all questions that bother me and the compiler should know the answers.</pre>Nexus-uk: <pre>I've needed a LLRB collection (<a href="https://github.com/petar/GoLLRB" rel="nofollow">https://github.com/petar/GoLLRB</a>) for <a href="https://github.com/Redundancy/go-sync" rel="nofollow">https://github.com/Redundancy/go-sync</a> I've also implemented my own collections for time-bucketed events, and circular buffers with particular requirements, which could be useful to re-use without casting. In at least one of those cases, I could provide one specialization for byte slices, and an interface{} one, but it's worse on any API that could really do with me returning a slice of objects (since that then involves casting every single element). Most of the time, it doesn't bother me - slices and maps are great primitives for a lot of things, but I can also see an argument that if you need something more, you don't want to copy, paste, fix-up types on a complicated implementation or take a hit casting (under a certain assumption, you're looking to use a specific algorithm and data type because it has the right characteristics and performance, and you probably don't want an overhead on that). I'd frequently be happy enough if I could wrap an implementation with casts that could be optimized away at compile time.</pre>Morningrise89: <pre>Absolutely agree,i have worked on generated code before and it is grueling and a bad decision every time I have seen it. Inheritance is a powerful feature, but too often it ends up being misused and you end up in a shoehorned mess. I prefer to only have embedding here... But I am not completely settled on that.</pre>natefinch: <pre>Really? every time I run into generated code, it's a huge blessing. It's guaranteed to conform to a standard. It's real actual code that is easy to reason about. If you trust the template, you don't even need to review it. For example, the syscall code in Go.... all the API calls are generated. It's a bunch of unsafe pointer conversion crap, and you can just totally ignore it and assume it's correct, because the template has been proven correct by people before you (and if there does end up being a bug, you fix it in the template and just regenerate).</pre>Rhodysurf: <pre>Because Go has inheritance with anonymous types Edit: i meant fields</pre>: <pre>[deleted]</pre>Rhodysurf: <pre>Thanks for the correction.. Yeah technically its delegation but it acts like inheritance, or its the closest thing to it ive found anyways</pre>davecheney: <pre>It does not act like inheritance, it is composition. </pre>skelterjohn: <pre>Negative, composition in go does not give you polymorphism.</pre>: <pre>[deleted]</pre>calebdoxsey: <pre>It's possible, but not likely to happen any time soon. I would suggest using a different programming language. Perhaps C# could do what you want. It has an asynchronous programming model using tasks (<a href="https://msdn.microsoft.com/en-us/library/dd537609(v=vs.110).aspx" rel="nofollow">https://msdn.microsoft.com/en-us/library/dd537609(v=vs.110).aspx</a>). <code>Task.Run</code> is basically equivalent to the <code>go</code> statement. <code>Task.WaitAny</code> is like <code>select</code> and you can implement channels using a <code>BlockingCollection</code> and the <code>Add</code> and <code>Take</code> methods. C# has been ignored by many programmers because Microsoft made it, but it has a ton of features.</pre>mparker762: <pre>It's async system is very slow. Go's goroutine implementation is multiple orders of magnitudes faster. C# async code produces huge amounts of garbage due to a need to work around limitations of the CLR. It is using a surprisingly heavyweight thread pool system that was designed for parallelism and long-running tasks but was reused as-is for their urgent concurrency needs that they inflicted on themselves with WinRT, instead of building a suitably light-weight system that was appropriate for the task. Not to mention that the async and await keywords are unnecessarily leaking the fact that the C# runtime is using a CPS/callback implementation, further constraining future concurrency advances.</pre>skelterjohn: <pre>Because when swapping composition for inheritance you feel clever (and your code is better, too). When you swap boilerplate repetition for generics, you feel dumb, since writing the extra code is more-or-less mindless.</pre>yen223: <pre>Because we can live without inheritance, but generics are useful for reasons that have been repeated ad nauseam.</pre>drvd: <pre>Because we all think of our future self as "the one guy who wrote this awesome do-it-all-with-anything framework which revolutionized web development"? Today nobody takes pride in a nice piece of code which does one thing properly and solves a specific, maybe even tiny, business need. You gain fame (or think you gain fame) only if your solution is useful in every imaginable way and solves a broad spectrum of problems in all domains equally well: A generic framework useful to process anything from uint8 to large cardinal numbers, from short 7bit ASCII strings to terabytes of UTF-18 encoded Klingon language with a custom collator, from clay tablets to Twitter feeds, from a simple struct to some business-entity discover-able through micro services. And programming (in the sense of "write code") is regarded as bad practice as it might not be DRY enough.</pre>egonelbre: <pre>IMO, it has to do with that inheritance is much much less useful than generics. I've been searching for a few years and I still haven't found something that would benefit from inheritance (when you have interfaces and embedding). Most of the time I needed to use inheritance was because I wanted to easily embed something or wanted to use interfaces, but the language support for them is terrible (I'm looking at you Delphi).</pre>comrade_donkey: <pre>What lead you to think that generic programming is inherently bound to subtyping? Don't take C++ or Java's implementations as references; they're off the table for a reason.</pre>davecheney: <pre>Nothing, they are independent, but I wonder why people are so happy to accept the position that Go does not support subtype inheritance, but are unwilling to accept the same position for templated types. </pre>comrade_donkey: <pre>Because implicitly implemented interfaces make up for the subtype polymorphism that doesn't come with embedding as it would with inheritance. The same could be true for a type-invariant generics implementation.</pre>lhxtx: <pre>Go has composition, which works better than inheritance IMNSHO. Animal Has a Dog instead of Dog is an animal is easier. </pre>calebdoxsey: <pre>I think most of those folks would see subtyping as a misfeature. Inheritance in classical OOP requires a virtual table indirection for method lookup. This is less efficient than direct function calls. As for generics, without them you either repeat yourself (<code>StringTree</code>, <code>IntTree</code>, ...) or lose efficiency and safety (boxed with runtime checks). The current ideal is both to move as much checking as possible to compile time, hence the push for sophisticated Haskellish type systems, to produce code that is as efficient as possible and therefore to give programmers as much control as possible over the execution of their program. But because of the language's design it will never meet that ideal. That's cool and all, the divide is ideological and probably fundamental, but the vitriol is kind of bizarre. (I mean if you don't like Go, and it's not going to change, why not use a different language?) Perhaps people are frustrated by the (apparent) waste of resources. With Google backing it, and the serious talent behind the language, they could've made a real C++ language competitor, but instead they created this half-finished, poorly designed bastard-child-of-C language, which is sadly becoming somewhat popular. (Go pulled off in 3 years what Haskell couldn't do in a quarter century)</pre>Tacticus: <pre><blockquote> Go pulled off in 3 years what Haskell couldn't do in a quarter century </blockquote> Because they settled on different goals and made the language useful.</pre>theonlycosmonaut: <pre><blockquote> Avoid success at all costs! </blockquote> (EDIT: for the uninitiated, that's Haskell's tongue-mostly-in-cheek unofficial slogan.)</pre>storm14k: <pre>Or perhaps people aren't actually frustrated (as its apparently gaining popularity) and its just an argument in a sounding box often repeated by folks who haven't even touched the language. I'm sure there are people that are using it that want generics but it doesn't seem like they are the ones carrying this argument.</pre>tealeg: <pre>Hmm, perhaps OOP is an overused paradigm, that contains a few good ideas, bundled in with things that make sense in a few cases, but actually create more problems than they solve. One of the reasons I love Go is that it seems like a distillation of the things that long experience shows are good, reliable, and understandable, and doesn't try to do everything that anyone ever thought of. Now, much of what I said also applies to the concept of "generics", but refugees of the Java and C++ worlds probably have enough experience of the downside of inheritance to accept it as not necessary, but see generics as a saving grace of their previous experience. Those people are one good Lisp course away from clamouring for Lisp style Macros. I'd join them, but if you really want to program that way, then you're probably going to have more fun with Lisp itself. Just my tuppence worth.</pre>howesteve: <pre>Actually, I miss methods overriding; i.e. A.foo() , B.foo(), B descends from A, calling A.foo() on a B instance, actually calls A.foo() while you want B.foo(). The rest is fair enough.</pre>Femaref: <pre>Considering there is no descends relationship in go (i.e. no inheritance; embedding is composition, not inheritance), method overriding makes no sense in go. </pre>howesteve: <pre>So what's the best way to solve that problem ? No matter how it's named.</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题