On Tue, Sep 11, 2018 at 5:28 PM robert engels <reng...@ix.netcom.com> wrote:
> 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 > but > it may be an indictment that Go’s lack of classes/inheritance/generics > leads to code bloat. > The top-answer also provides a different explanation, in that Kubernetes contains a lot more features than the others mentioned in the question. I don't think it's an apples-to-apples comparison. (leaving aside the fact how useless I think SLOC are as a measure of complexity, but since you brought it up :) ) I would be curious as to what the stumbling block was. > Mostly overabstraction making it hard to understand what was going on "under the hood" and hiding the call graph and dependencies from static analysis. 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?**”* > That is my reading. > and as I pointed out, Go’s method dispatch is already slower than Java in > both the direct and interface cases. > I don't believe your benchmark transfers (as I mentioned). Java and Go are very different languages and implementations. The fact that Java has a JIT alone means that it is favored by this particular microbenchmark. Personally, I'd argue that if anything, your benchmark proves the point quite well: In Go, which is the language we are talking about, dynamic dispatch is ~4x slower than static dispatch. In Java, FTR, static dispatch is *also* faster than dynamic dispatch. It's just that the JIT is able to convert more situations from one to the other, which lets it make up for that in part. But being JIT-compiled comes with other tradeoffs and those tradeoffs aren't necessarily right for Go. People have proposed interface based generics for Go, and the criticism is > most of the time - that will be slower... > I am not sure this is the case. Most founded criticism I've heard is that it doesn't provide a way to model operators in generic code. I don't believe that it's at all slower and AFAIK neither does Ian (I can't speak for him of course. But I seem to remember him mentioning that at Gophercon). So, maybe most people criticize that, but then I'd happily disagree with them. > > 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. > For more options, visit 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.
