I am well aware of mechanical sympathy and the techniques (like the disrupter) used (I would counter that in many cases you are not writing “Java” due to the object pooling ,etc.)
What I’ve shown is that Java is already more performant than Go without using those techniques for many application aspects - specifically in terms of method dispatch, but still Go direct methods vs interface methods are 5x faster, so you if you need ultra performance critical code you need to keep that in mind, but RARELY is this the case (except for some people in HFT but even they have moved on to FPGAs) and you are far better structuring your code for maintainability and functionality rather than worrying about slower method dispatch... ArrayList<byte> is not “correct” Java - because you are going to encode every byte as an object in an object[] behind the scenes, and each would need to be managed as an Object. Java has arrays, you would simply use a byte[]. If you need expandable arrays, you would probably use a ByteBuffer. Your point highlights an important consideration - most people don’t know how to write REALLY performant software in a given language unless it is an area of focus and experience, which is why I distribute the tests publicly because I will grant that there may be techniques in Go that I am not understanding or misusing - but at this point I think I have a pretty good handle on the internal workings of Go. The biggest performance advantage for Go will be the garbage collector due to the “value type” of array struct, since there is only a single reference to be GC managed regardless of the number of elements. That is not possible in Java - at least not now. That being said, there are Java VMs like Azul Zing that are far more performant than Go in terms of GC pauses without any restricting on the layout of the memory being managed. As soon as you start using array of interface in Go, you are going to put pressure on the GC, as the number of references that need to be managed expands proportional to the size of the array - at least I think so - but there may be behind the scenes escape analysis that determines if any references escape the array, and if not it can still manage it is a single reference. But all of this is off-topic from the original post - which was to suggest to keep it simple and use interfaces/closures at runtime to support generics and not worrying about the performance overhead - the really performance critical coders can always write non-generic/interface containers if they absolutely think they need it, but most likely they don’t... > On Sep 11, 2018, at 11:57 PM, Egon <egonel...@gmail.com> wrote: > > > > On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote: > >> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts <golan...@ >> <>googlegroups.com <http://googlegroups.com/>> wrote: >> >> [golang-nuts to CC, golang-dev to BCC] >> >> On Mon, Sep 10, 2018 at 5:33 PM robert engels <ren...@ <>ix.netcom.com >> <http://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... > > > I think you haven't seen what people need to do in Java to make it > performant. As an example: > > https://mechanical-sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html > > <https://mechanical-sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html> > > That example is more about value types, but also implicitly a problem with > boxing. > > The boxing overhead is most visible with having things like ArrayList<byte>. > > Indeed there are places where Java can erase some of the performance > overhead, even more so with GraalVM. (Not sure about the memory overhead) > > >> 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...@ <>googlegroups.com <http://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 > <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.
