On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote:
> On 2/16/2014 10:59 PM, logicchains wrote:
>> On Sunday, 16 February 2014 at 20:29:04 UTC, Walter Bright wrote:
>>> It's not exactly true. What has happened is I spent a LOT of time
>>> trying to make my C/C++ compiler fast. That experience has enabled me
>>> to design D so it is fundamentally fast to compile, and enabled me to
>>> pick an internal design for the compiler that I know will be fast.
>>
>> Isn't this kind of the point? The Go devs don't have the somewhat unique
>> experience of having written a C++ compiler from scratch to guide them
>> in implementing generics in Go,
>
> The Go devs have some pretty strong backgrounds themselves. I think it's reasonable to figure they can handle the task just fine.

I partly agree.

If you follow the discussions, they seem to focus mainly in Java, C++, while ignoring D, Ada, Eiffel, Modula-3, OCaml, Haskell, .NET and a few others.

> Besides, I suspect the #1 optimization in making a fast-to-compile language is just simply "Don't make C++".

Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then.

--
Paulo

On Monday, 17 February 2014 at 03:48:28 UTC, Nick Sabalausky wrote:
>> ------- Forwarded Message --------
>>> From: Aram Hăvărneanu <aram.h@mgk.ro>
>>> To: Jonathan Amsterdam <jbamsterdam@gmail.com>
>>> Cc: golang-nuts <golang-nuts@googlegroups.com>, Michael Jones
>>> <mtj@google.com>, Jonathan Barnard <jonathan.t.barnard@gmail.com>
>>> Subject: Re: [go-nuts] Re: Generics false dichotomy
>>> Date: Sun, 16 Feb 2014 11:03:38 +0100
>>>
>>> D pays a huge penalty in compilation speed for generics. D generics
>>> are turing complete, making compilation time potentially unbounded.
>>> Dmd might build their standard library quickly, but this says nothing
>>> about the fundamental issue.
>>>
>>> Potentially unbounded compilation times are unacceptable for Go.
>>>
>
> Go pays a huge penalty in execution speed. Go is turing complete, making runtime potentially unbounded. The programs written in Go that have actually been created might execute quickly, but this says nothing about the fundamental issue.
>
> Potentially unbounded execution times are unacceptable for D.
>
> But Go's fundamental problems don't even stop there. In order to build even just the Go compiler itself, a series of shell scripts are provided <http://code.google.com/p/go/source/browse/src>. Batch and bash are both turing complete, therefore Go's very own buildscripts have potentially unbounded compilation times. In reality, they won't actually execute forever unless someone screws up and does something stupid, but reality, of course, is unimportant. What's *really* important here are highly unlikely scenarios that have yet to ever actually surface and can't be handled without resorting to such inexcusably difficult and drastic measures as pressing Ctrl and C simultaneously.
>
> Go-nuts really is nuts, apparently.

Worse, is that they think as acceptable to create templating tools, similar to what Borland and others offered with their compilers when templates started to be discusses at ISO.

Sometime around the mid 90's, almost 20 years ago!

Having a strong typed language without generics support in the 21st century is not understandable.

--
Paulo

On 2/16/14, 12:09 PM, Russel Winder wrote:
> Someone with serious knowledge should wade into this campaign of FUD.
> The whole thread is wrong-headed.

Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ

Andrei

On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote:
> On 2/16/14, 12:09 PM, Russel Winder wrote:
>> Someone with serious knowledge should wade into this campaign of FUD.
>> The whole thread is wrong-headed.
>
> Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ
>
> Andrei

It looks like you've been completely ignored.

And I love how the Sort package is their great example of implementing a generic algorithm. I consider it a package which demonstrates the problem with lack of generics.

On 2/17/14, 10:59 AM, Jesse Phillips wrote:
> On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote:
>> On 2/16/14, 12:09 PM, Russel Winder wrote:
>>> Someone with serious knowledge should wade into this campaign of FUD.
>>> The whole thread is wrong-headed.
>>
>> Thanks for mentioning this. It's an interesting thread. I posted a
>> response:
>> https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ
>>
>>
>> Andrei
>
> It looks like you've been completely ignored.

This may be partly a logistics issue - my name appears garbled.

> And I love how the Sort package is their great example of implementing a
> generic algorithm. I consider it a package which demonstrates the
> problem with lack of generics.

I would agree that Go's sort tends to confuse people about what problems can and cannot be solved with Go-style interfaces.


Andrei

Am 17.02.2014 20:08, schrieb Andrei Alexandrescu:
> On 2/17/14, 10:59 AM, Jesse Phillips wrote:
>> On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote:
>>> On 2/16/14, 12:09 PM, Russel Winder wrote:
>>>> Someone with serious knowledge should wade into this campaign of FUD.
>>>> The whole thread is wrong-headed.
>>>
>>> Thanks for mentioning this. It's an interesting thread. I posted a
>>> response:
>>> https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ
>>>
>>>
>>>
>>> Andrei
>>
>> It looks like you've been completely ignored.
>
> This may be partly a logistics issue - my name appears garbled.
>
>> And I love how the Sort package is their great example of implementing a
>> generic algorithm. I consider it a package which demonstrates the
>> problem with lack of generics.
>
> I would agree that Go's sort tends to confuse people about what problems
> can and cannot be solved with Go-style interfaces.
>
>
> Andrei
>

You have provided a very nice answer.

The problem with Go generics is religious, I might have to eat my own words, but I seriously doubt they will ever support it.

They are too focused with Java and C++ as models, to accept anything else as proof of them being wrong.

--
Paulo

On Mon, 2014-02-17 at 21:00 +0100, Paulo Pinto wrote:
> Am 17.02.2014 20:08, schrieb Andrei Alexandrescu:
> > On 2/17/14, 10:59 AM, Jesse Phillips wrote:
> >> On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote:
> >>> On 2/16/14, 12:09 PM, Russel Winder wrote:
> >>>> Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed.
> >>>
> >>> Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ
> >>>
> >>>
> >>>
> >>> Andrei
> >>
> >> It looks like you've been completely ignored.
> >
> > This may be partly a logistics issue - my name appears garbled.
> >
> >> And I love how the Sort package is their great example of implementing a generic algorithm. I consider it a package which demonstrates the problem with lack of generics.

It is hard to disagree, and I really like Go for its goroutines and channels.

> > I would agree that Go's sort tends to confuse people about what problems can and cannot be solved with Go-style interfaces.
> >
> >
> > Andrei
> >
> 
> You have provided a very nice answer.
> 
> The problem with Go generics is religious, I might have to eat my own words, but I seriously doubt they will ever support it.

There does appear to be a level of intransigence about the expression of the opinion, and indeed the whole dichotomy. I admire the attempt to provide strongly typed duck typing, and the challenge to the need for generics as an orthodoxy. However there is a time to declare a position not entirely viable and to look for a solution. My feeling is the Go core team should move from "we haven't seen a generics system we like" to "we are actively investigating a generics system for Go". Sadly this can only be for Go 2 since they have declared an absolute backward compatibility position for Go 1.

> They are too focused with Java and C++ as models, to accept anything else as proof of them being wrong.

Not to mention C#. And OCaml and Haskell.

Sadly I don't have the time in the near future to try and design and implement a CSP (process and channels) system for D. Currently JCSP, C ++CSP2, PyCSP, Python-CSP are the realizations of CSP I know of, and all of them were a lot of work.

Go has effectively proved that CSP (or at least it's equivalence of it: Rob Pike maintains he developed hos ideas independently in the Newsqueak, Alef, Limbo sequence) is an extremely sensible architecture for high performance concurrency and parallelism in a commercial context. Analogously DataRush has shown the effectiveness of a more general dataflow model in Big Data.

What we really need is a couple of PhD students to work on this.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote:
> On 2/16/14, 12:09 PM, Russel Winder wrote:
>> Someone with serious knowledge should wade into this campaign of FUD.
>> The whole thread is wrong-headed.
>
> Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ
>
> Andrei

The fears about "slow code" are especially odd since ad-hoc templates are an important tool to force constant folding and many optimizations that requires inlining.

Moreover Go with first its class interface{} values will pay a heavy price in dynamic dispatch, something that is optional and not really "pay what you use".

Granted code bloat is a real thing and you _might_ have instruction cache problems, but the problem only ever show itself when the working set of code exceed the instruction cache capacity. Ie. a huge executable might not be a good predictor for reduced instruction cache efficiency.

On Monday, 17 February 2014 at 22:19:24 UTC, ponce wrote:
>
> Granted code bloat is a real thing and you _might_ have instruction cache problems, but the problem only ever show itself when the working set of code exceed the instruction cache capacity. Ie. a huge executable might not be a good predictor for reduced instruction cache efficiency.

I heard a story of a C++ gamedev team that would use type-punning to reduce code size. std::vector<void*> would be the only instantiation of std::vector + casts everywhere. That was for console binaries.

On Monday, 17 February 2014 at 03:59:15 UTC, logicchains wrote:
> On Sunday, 16 February 2014 at 20:29:04 UTC, Walter Bright wrote:
>> It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast.
>
> Isn't this kind of the point? The Go devs don't have the somewhat unique experience of having written a C++ compiler from scratch to guide them in implementing generics in Go, so it doesn't make practical sense to say "D has fast-compiling generics, so why can't Go?". Just because a good generics system is theoretically possible, doesn't mean it's easy to design. Personally, I think comparing C++ to C shows that no generics is better than poorly designed generics (C++ templates).

I don't think so. Did you know that some of they are the same guys from Bell Labs which created C, UNIX, Plan9, UTF8 etc?