4 ms·

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 rel

by gnode 7y ago

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.

zeppelin101 7y ago
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.
- pmoriarty 7y ago
  Think of how much more benefit they'd have had, had they chosen an even simpler language like Scheme.
  - ncmncm 7y ago
    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.
icholy 7y ago
JavaScript has a much bigger community/ecosystem that Go. However, Go libraries are (on average) much higher in quality.
- pmoriarty 7y ago
  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.
  - gnode 7y ago
    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.
skohan 7y ago
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.
- AnimalMuppet 7y ago
  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.
  - skohan 7y ago
    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.
deleted 7y ago
[deleted]
tandr 7y ago
>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.
pjmlp 7y ago
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.
- watergatorman 7y ago
  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

by gnode 7y ago

zeppelin101 7y ago

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.

pmoriarty 7y ago
Think of how much more benefit they'd have had, had they chosen an even simpler language like Scheme.
- ncmncm 7y ago
  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.

icholy 7y ago

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

pmoriarty 7y ago
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.
- gnode 7y ago
  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.

skohan 7y ago

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.

AnimalMuppet 7y ago
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.
- skohan 7y ago
  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.

deleted 7y ago

[deleted]

tandr 7y ago

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

pjmlp 7y ago

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.

watergatorman 7y ago
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