D vs Go in real life

[Bienlein]

On Friday, 29 November 2013 at 12:53:02 UTC, Chris wrote:

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

Agree. If I accept a language that simple then it needs to 
deliver execution speed. And Go fails in that domain.

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

The question I ask myself whether delegation is a nglected gross 
concept. I don't mean 1:1 associations as such, of course, but I 
mean that you can simply say myStruct1-fieldN instead of 
myStruct1->field1-> ... myStructN->fieldN.

>But we do have delegation in D and it is a useful feature in 
>Objective-C too.

Concerning D you mean mixins? Yeah, I wonder why no JVM language 
has them. On the JVM all languages on a higher level than Java 
have chosen to go with traits only (Scala, Kotlin). Groovy has 
the @Delegate annotation, but the Groovy compiler doesn't 
complain in case some diamond problem pops up in your code. So 
it's not truly for real.

With regard to Objective-C you mean the 
instancesRespondToSelector: thing? But this is some kind of hack. 
In Go the compiler checks for correctness.

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

Well, at least Go is very consistent. No tons of complicated 
special cases you need to know about. Rust did things very well 
here. It is made for speed and low memory consumption. The way it 
adds OO elements to the language is not that minimalistic.

I don't see how Go can compete with Java when a company is 
already using Java as Go runs at about the same speed. They have 
done concurrency very well with goroutines and channels. Some of 
the excitement about Go clearly comes from concurrency being well 
done. They have a tool that can analyse the channels in some Go 
code and tell you whether a deadlock is inevitably bound to 
happen. That's not bad. I think Go is more for C or Python people 
and for Java/.NET people that want to do a little bit of system 
programming in their spare time.

-- Bienlein