Hacker News Reader

Comment by gnode | Hacker News Reader

I'd say Go's success is almost nothing to do with its design, and everything to do with social factors.

Rob Pike was famous before its creation (within the relevant community). The language was designed within Google, and gained much hype from that. The effort to foster a community paid dividends.

Writing Go code for a living, I find it a very mediocre language. It's largely redeemed by its library ecosystem, which reflects not on the language, but the enormous size of its community and commercial backing.

If anything is noteworthy about its design, it's that it's simple (crucially, to those already familiar with C-like languages), and easy to bring people on board. What is lost for want of features and abstractions, is gained in human resource.

View on HN

I have the perception that Go is more optimized for meeting organizational needs than programmer needs: it's simplicity and limited abstraction make it more difficult to write complex, serpentine code which is difficult to understand without a deep knowledge of the codebases.

For an experienced developer that might feel a bit like handcuffs: like you have to write more redundant code and handle things at a more literal level than you could get away with in other languages.

However, it tends to result in a codebase that's more resilient to turnover: if someone new joins the team there's going to be less specific understanding about the inner workings of the codebase they need to sit down and understand what they're looking at. It also limits the damage a mediocre developer can do through overuse of bad abstractions.

I agree with your last paragraph. However, I assert that the virtues you name there are in fact more for meeting organizational needs than programmer needs.

And that's fine. As a software system gets bigger, the organizational issues come to outweigh the programming ones.

I think we are in agreement. My assertion is exactly that Go favors organizational needs over programmer needs, and the examples I gave are evidence of that.

I'm not making a value judgement over whether that priority is a good or a bad thing, just an observation about the nature of Go.

>I find it a very mediocre language >... >What is lost for want of features and abstractions, is gained in human resource.

I cannot agree more, and I am writing Go for living too. Thank you very much for expressing it so accurately.

I think your last paragraph is key here. Go is a simple language, which makes it practical for large projects, with many collaborators, some of whom might be fresh out of school. Google must have benefited internally a lot by Go.

Think of how much more benefit they'd have had, had they chosen an even simpler language like Scheme.

Exactly. Scheme has not been a success in part because it lacks needed features. Go has just enough for its uses, and no more. It's not powerful enough for really serious projects, but (1) there are already other languages for those, and (2) the overwhelming majority of projects aren't.

JavaScript has a much bigger community/ecosystem that Go. However, Go libraries are (on average) much higher in quality.

Early adopters of a language tend to be relatively highly skilled and tend to write better code, while when language becomes enormously popular the majority of software written in it tends to revert to the mean.

I'm not sure that principle applies well to JavaScript. It was popular almost from the get-go, being the only language of the Web. A lot of bad practises were popular in the early days.

JavaScript has changed a lot as a language over time -- ECMAScript 2019 makes it a lot easier to write good code than the original JavaScript. It's now better understood how to write JavaScript code, and how not to.

Go is basically Limbo with a bit of Oberon-2 on top.

Limbo did not went far, even though you can still play around with it.

IMHO, Oberon-2 WithStmt has much cleaner syntax than Go TypeSwitchStmt.

WithStmt is easier to parse, more general and it doesn't need the Primary "." "(" "type" ")" at the beginning which appears only needed to distinguish Go ExpressionSwitchStmt from Go TypeSwitchStmt.

wgator2

Reply on news.ycombinator.com