The main sell point of Go is not simplicity, but overall balance and flexibility

Many articles think, and some surveys suggest, simplicity is the main reason why Go becomes popular. I have different opinions.

Go is not the simplest language among popular ones, it is neither from syntax view nor concept set view.

In my opinion, the reason why Go becomes popular depends on many factors:

1. Go is supported by Google and embraced by the industry.
2. Go programs have not an obvious weak point, though they are also not the strongest (comparing to other languages) in each of these points, which includes
   • memory saving
   • fast warming-up
   • fast execution speed
   • good reflection support
   • good static analysis support (tools)
   • good code readability
   • good cross-platform support
   • great guarantee for keeping compatibility
   • not complex
3. Go filled the blank of lacking of a static language which is still much flexible in the world.

Honestly, the second factor is the most important one to Go's success. However, personally, I think the last factor is the main sell point of Go.

Specifically, Go's flexibility is mainly reflect in the following aspects:

• great type deduction support in Go.
• supporting a unique and interesting (and flexible) built-in concurrency programming model.
• supporting function values perfectly.

Let's view some examples of the last aspect.

In Go, we can use methods as general function values:

package main

type C struct {
	Name string
}

func (c *C) M() {
	println(c.Name)
}

func g(f func()) {
	f()
}

func main() {
    var c = C{"foo"}
    g(c.M) // foo
}

Of all the other static languages I have used, I feel they are all too rigid, in an unexpected way. For example, C++ doesn't support using methods (member functions) as function values.

class C {
  public:
    void M() {}
};

void f() {}

void g(void (*fptr)()) {
    fptr();
}

int main() {
  C c;
  
  g(f);     // ok
  //g(c.M); // not ok
  
  return 0;
}

(Yes, we can use the following shown JavaScript way with the help of std::bind and std::function to use member functions as callbacks, but this is so weird, verbose, and unnatural.)

Java even doesn't support function values. A single-method interface is needed to simulate function callbacks.

Many languages introduce lambda expressions to add some flexibility. But this doesn't solve the rigid problem, member functions still can't be used as function values. (Supporting lambda expressions is a compensation, not a solution, to become flexible.)

JavaScript is a dynamic language which supports function values. It really supports using member functions as function values, but the receiver context (or this in JavaScript) is lost in the process. Programmers must bind a member function and an object together explicitly. This is some weird and counter-intuitive. (In fact, this is not the only place exposes the weirdness of this context in JavaScript.)

class C {
  constructor(name) {
    this.name = name;
  }
  
  M() {
    console.log(this.name);
  }
}

function g(f) {
  f();
}

var r = new C("bar");
r.M();
r.M = r.M.bind(r); // If this line is missing, 
                   // the next line will run error:
                   // TypeError: Cannot read property 'name' of undefined
g(r.M);

Although JavaScript support function values well (despite the just mentioned drawback), now it also supports arrow functions (kind of lambda expressions), which in fact is not a necessary feature for JavaScript. I often have a feeling that JavaScript is becoming another C++ by supporting many new features (with duplicated functionalities) in recent years in a surprising pace, which results that there are many ways to do the same thing in modern JavaScript.