I only brought up LOC from the stand point that a 10 line program is most likely trivial to maintain. A million line program in any language is a different beast, and some are better suited for that “size”
I agree with you whole heartedly that Go and Java are different beasts. I wasn’t a fan of some of the additions to Java either... the more I use Go, as I said before, it is perfect for certain classes of apps, and the generics proposals just don’t seem to fit well IMO, but I don’t have enough real world Go experience to layout a perfect proposal - just surgical strikes - and is why I, and suggest others, look at real world applications to see how the proposal would work/benefit. I appreciate the feedback. > On Sep 11, 2018, at 10:50 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > >> 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. -- 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.
