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 <javascript:>> wrote:
>
> [golang-nuts to CC, golang-dev to BCC]
>
> On Mon, Sep 10, 2018 at 5:33 PM robert engels <ren...@ix.netcom.com
> <javascript:>> 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
> 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 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
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 <javascript:>.
> 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.
