D vs Go in real life

[Chris]

bearophile

I wonder, if it's just the way I've learned how to program that I 
prefer

byte[] buf;

to

buf []byte; // Which seems a bit awkward to me. "it's called 
'buf' and it is an array of ... of what???? Drum roll r-r-r-r-r 
... Of bytes! Yeah!!!

Maybe it's because in my culture we read (and think?) from left 
to right. Mind you, the apple symbol on the Mac is in the upper 
left corner. The "Launcher" in Ubuntu is on the left hand side by 
default. The folders and contacts in Gmail are on the left hand 
side. Your mouse cursor is in the left half of the screen most of 
the time.

On Friday, 29 November 2013 at 12:16:07 UTC, Bienlein wrote:
> On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote:
>>
>> [1] Raises the question whether we've been conditioned by C or 
>> whether C was intuitive.
>
> My theory is that Go is from the beginning intended to be a 
> modernized C. If I look at C from that perspective I can always 
> explain why things in Go are the way they are. The syntax is 
> only in part awkward as Go is in some ways inspired by Oberon.

Very good point. But do we need to modernize C? C is only one 
step away form assembly. So if you modernize this, your still on 
the same level.

> But what suprises me is that with a language feature as simple 
> as delegates you can solve so many design problems that well. I 
> wonder whether this is a result of a lot of thought or only a 
> result of adding some language feature that frees you from 
> having to write myStruct1->field1->myStruct2->field2-> ...

I like structs and classes for the fact that they can handle 
stuff on their own. But we do have delegation in D and it is a 
useful feature in Objective-C too. structs/classes and delegation 
are not mutually exclusive. And your question is very good. Is 
delegation in Go a "work around" within a limited language or is 
it a design feature?

If Go is modernized C, will it end up like C++?