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
