Google's Go

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Jan 25 07:20:27 PST 2010


grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> Adam D. Ruppe wrote:
>>>> On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
>>>>> I see that Go has now usurped D's former place at #13 in Tiobe - 
>>>>> which I realize of course does not mean anything. But I'd be 
>>>>> interested to hear what the D aficionados think of Go.
>>>>
>>>> There's been a couple threads about it before. My opinion: it is 
>>>> garbage.
>>>> It has maybe two or three good ideas in there, but on the whole, it is
>>>> a very poor showing. The arrogant developers didn't do any research 
>>>> into
>>>> prior art when designing it, and it shows - good ideas are absent 
>>>> without
>>>> even a mention. Bad ideas remain in there saying "this is the best 
>>>> we could
>>>> do".
>>>
>>> Oh well, D isn't that great either. While it doesn't have such big 
>>> names attached on it (although "Andrei" is not that small of a name), 
>>> it had more time.
>>>
>>> What worries one most is how D rushes "to completion", just because 
>>> of the deadline of that one book. It's obvious that some features are 
>>> half cooked at best. Just look at the features added in D 2.038 (auto 
>>> ref, DIP2): terrible hacks to get some broken language features 
>>> barely to work before the deadline is over.
>>
>> Meh. It's all so subjective, calling some language design "a hack" is
>> nonfalsifiable. That reminds me of some of the Walter/Bartosz/me
>> discussions. The first person to call something a hack usually won any
>> argument because there was no way to counter that label sensibly.
>> Prepend "terrible" and we have a winner.
> 
> I guess that's true. I also don't want to start a discussion about 
> "taste" or whatever.
> 
> Let me just say that those are unorthogonal, single-trick-pony features. 
> They don't add too much value to the language, and are specially 
> designed to cover for some annoying corner cases of other features.
> 
> Please tell me how auto ref template parameters are universally useful?

Sorry, I forgot to answer these questions earlier. First off, going from 
unwarranted presuppositions to actual questions is definite progress.

Auto ref is a long-standing need that D has had and has particular 
applications to SafeD. An example is getopt():

string user, site;
getopt("user", &user, "site", &site);

This call has a mix of rvalues and pointers in the call. In SafeD there 
is pressure for eliminating pointers, so ideally getopt() should be 
rewritten to accept:

getopt("user", user, "site", site);

In that case, getopt() must properly deal with mixed by-value and 
by-reference arguments.

Another issue is perfect forwarding. If you have a function fun you 
can't define another function gun that forwards to fun and has the same 
effect. This is the hallmark of functional composition, and in a 
language with the option of passing by reference is a big challenge. C++ 
does not allow perfect forwarding, which turned out to be a crippling 
problem that has spurred a Sisyphic quest for partially assuaging that 
problem.

Without auto ref and auto ref returns, D did not have perfect 
forwarding, and much nontrivial code was in a world of pain. A simple 
example was that ranges that enhance other ranges can't forward front() 
to the ranges they manage. I mentioned this before - just search this file:

http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/range.d

for "mixin".

I'd mentioned this rationale once.

> Or how inout(T) isn't just a shortcut to avoid writing 
> const/immutable-aware code 3 times or putting it into a template?

I don't even understand the question. You're asking "how motherhood and 
apple pie aren't just great things?" I'm glad Steve took the time to 
answer that in detail.

> What's 
> the use of auto ref returns, other than a small performance 
> optimization? (Though I admit that min() example in the spec is cute.) 

See above.

> Especially inout(T) seems to be only useful in one specialized situation.

It's a family of situation that experience with C++ has made clear is a 
big issue.

> Could be that I'm lacking foresight, but then those questions above 
> should be simply to answer.

I wouldn't put it on lack of foresight more than attitude. The questions 
above are indeed simple to answer, and the answer does occur easily to 
the willing.


Andrei



More information about the Digitalmars-d mailing list