Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed.

------- 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
> 
> On Sun, Feb 16, 2014 at 2:51 AM, Jonathan Amsterdam <jbamsterdam@gmail.com> wrote:
> > D doesn't pay too much of a compilation penalty for its generics
> 
> 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.
> 
> -- 
> Aram Hăvărneanu
> 
> -- 
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 2/16/2014 12:09 PM, Russel Winder wrote:
> Someone with serious knowledge should wade into this campaign of FUD.
> The whole thread is wrong-headed.

A handy link:

https://groups.google.com/forum/#!topic/golang-nuts/rxOz-QMyHr4

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

I enjoyed this comment:

"The D guys have thrown a lot of time behind making their compiler fast"

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.

The actual time I've spent profiling and tuning DMD for speed has been minimal, though I've still gotten caught by a few mistakes.

And there's this regression:

https://d.puremagic.com/issues/show_bug.cgi?id=12137

Russel Winder:

[Quoted]
>> Potentially unbounded compilation times are unacceptable for Go.

That person still has to realize that in D there's also compile-time function execution, that could lead to equally unbounded compilation times, and is currently quite slow... :-)

Bye,
bearophile

Am 16.02.2014 21:29, schrieb Walter Bright:
> On 2/16/2014 12:09 PM, Russel Winder wrote:
>> Someone with serious knowledge should wade into this campaign of FUD.
>> The whole thread is wrong-headed.
>
> I enjoyed this comment:
>
> "The D guys have thrown a lot of time behind making their compiler fast"
>
> 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.
>
> The actual time I've spent profiling and tuning DMD for speed has been
> minimal, though I've still gotten caught by a few mistakes.
>
> And there's this regression:
>
> https://d.puremagic.com/issues/show_bug.cgi?id=12137

Walter, they tend to speak about Go compilation times as if Modula-2, Turbo Pascal, and who knows what else, didn't already had that in the mid-80's.

Go's fast compilation times are easy to sell to developers that never used native code compilers besides C and C++ ones.

So many in the Go community think it was kind of an achievement of language toolchain.

--
Paulo

On 2/16/2014 12:54 PM, bearophile wrote:
> That person still has to realize that in D there's also compile-time function
> execution, that could lead to equally unbounded compilation times,

Amazingly, D hasn't solved the halting problem. I'm so ashamed :-)

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

"However, I agree that there may well be other reasons to not have them in Go, such as their simply not being especially useful in day-to-day programming; but I don't have enough experience with meta-programming to make such a judgment."

Some years ago, I felt exactly the same way about generics. I have recently written some very interesting D programs, and I would have shocked my former self with nearly every function being a template.

> ------- 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.

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).

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