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.

Reply via email to