> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > [golang-nuts to CC, golang-dev to BCC] > > On Mon, Sep 10, 2018 at 5:33 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > In the entire codebase of Docker I could find only one obvious use of > interface{}, and no type casts. > > Generics are not only useful for functions taking interface{}. They are also > useful for functions taking non-empty interfaces, for cases where you could > re-use an existing generic implementation and forego re-implementing it for > your concrete type and for reducing boilerplate across many types (e.g. the > famous sort.Interface).
True, and reviewing cockroachdb shows the sort.Interface used a lot, and a generic container could avoid that, but in most cases this could be solved by only having to implement Less and having ’sort’ work on slices - as the vast majority are slices to begin with. I am just attempting to point out that the original Go designers offered ’typed’ collections (slice, map) as part of the language. They fall short in some ways but it may be possible for a simpler solution to expand their abilities, or add others, without resorting to generics. I like the simplicity and readability “no surprises for the most part” of Go, and I think it should try to stay that way. > > In my opinion, Go isn’t suitable for large enterprise systems with million+ > lines of code > > No offense, but empirically, the existence of such systems written in Go > seems to contradict you here. Kubernetes has 3.5M lines of code in just the > single main repository. And that's just open source software - most of the > actual million+ lines of code systems written in Go you won't know about, > because they are not open (I work on one of those). This seems to contradict this a bit, https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container <https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container> but it may be an indictment that Go’s lack of classes/inheritance/generics leads to code bloat. I believe that you work on a large Go system, I am just not positive it is pleasurable to maintain/refactor - maybe for high knowledge original authors - but as I said I am going to leave that criticism to another post, as it is not particular germane to the generics discussion. > > The Java generic code is a pleasure to use, and maintain > > I believe this is up to individual perception. Personally, I found working on > a large-scale Java codebase to be an unpleasant experience, because of the > generic code. I would be curious as to what the stumbling block was. I’ve seen Tuple<Long,Long> used in public APIs in some code bases - where a typed class that wraps it is for more appropriate - not good, and very poor maintainability. > > But, people cry, boxing is SLOW, and we want Go to be FAST! This paper > https://research.swtch.com/generic <https://research.swtch.com/generic> is > citied multiple times as a charge against boxing. > > Not quite. That article is cited to clarify that you need to decide on what > tradeoff you want to make and to justify it. Boxing - choosing "slow > programs" in the parlance of the article - is a reasonable choice to make, > but you should do so deliberately and make a good case for why it's the right > choice. > > It's also used as a reference to quickly explain one example of the current > design, which is that it makes that decision no longer a language decision, > but an implementation decision. i.e. we don't even know if generics in Go > will be boxed or not - we can decide that later and change the decision at > will. > I disagree with your reading here. The statement from the article is "do you want slow programmers, slow compilers and bloated binaries, or slow execution times?” and as I pointed out, Go’s method dispatch is already slower than Java in both the direct and interface cases. So citing Java and ‘slow execution times’ as a problem with generics s incorrect by the author, and that people keep citing it as fact is troublesome. People have proposed interface based generics for Go, and the criticism is most of the time - that will be slower... > Now the reason for this is almost certainly that Java can inline across > virtual function calls > > I would say that the core advantage of Java is likely that it is JIT-compiled > and as such can do a whole bunch of optimizations that an AOT-compiled > language like Go can't do. But I might be wrong. > > I also don't think it matters a lot. I think it's more important what works > for Go, than what worked for Java. The two languages are very different in > both semantics and implementation. Conclusions from one don't necessarily > transfer to the other. > Exactly, Go is very simple, and ideal for the cases I pointed out in the original post (and I’ll add, micro-services too), and so far all of the proposals that seem to be gaining traction don’t continue that design paradigm. > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
