Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"

[Jakob Ovrum via Digitalmars-d-announce]

On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu 
wrote:
> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
>
> Andrei

As I know Gary is sometimes (often?) on these forums I'll post 
some critique here. Misrepresenting Go in a comparison with D 
doesn't reflect well on the D community, so please have a look at 
the following issues:

In the first code example, the Go version returns 1 on failure 
and 0 on success, while the D version always returns 0. Also, the 
Go version correctly uses stderr for error messages while the D 
version uses stdout for everything.

In the second example maybe you should print four lists to be 
equivalent of the Go code. I think it's misrepresentative to 
shorten the D example by making it do less work.

> auto text   = source.byLine.join.to!(string);

This is not safe as byLine reuses the same buffer for every line. 
It may or may not work depending on join's implementation. Also, 
it's idiomatic to omit parantheses when a template argument list 
consists of a single token: source.byLine.join.to!string;

> With all that said, I honestly think Go’s design a disservice 
> to intelligent programmers.

s/design a disservice/design is a disservice/

> From my experience of using Go it’s just too simple to create 
> useful abstractions.

This sentence is ambiguous and could be taken to mean it's really 
simple to create useful abstractions in Go. The intended meaning 
is obvious with context, but it threw me off for a second...

> I guess by now Go programmers reading this will be frothing at 
> the mouth shouting “Your doing it wrong!”.

s/your/you're/

That could be misconstrued as a jab at the intelligence of Go 
programmers, which I don't think serves your cause.

> Well, there is another way of implementing generic functions 
> and data types, and that is to completely break the type system!

Didn't you just say there was simply no way around it?

> I know object-oriented programming is no silver bullet but it 
> would of been nice to be able to abstract details away into 
> types and provide better encapsulation.

s/would of/would have/

Also, this statement just begs for responses pointing to Go's OOP 
features. It has both user-defined types and encapsulation 
features.