[golang-nuts to CC, golang-dev to BCC]
On Mon, Sep 10, 2018 at 5:33 PM robert engels <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).
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).
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.
But, people cry, boxing is SLOW, and we want Go to be FAST! This paper
> 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.
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.
--
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.
