Read "Why I give up go language"

Recently familiar with the next go language, found that go language and many poorly designed places, and then read the "Why I give up go language" this article, for some aspects, I still more agree.

This article summarizes 16 points, as follows:

1.1 Do not allow left curly braces to start another line

1.2 The compiler inexplicably adds a semicolon to the end of the line

1.3 Extreme emphasis on the speed of compilation, regardless of the function should be provided

1.4 Error handling mechanism too primitive

1.5 garbage collector (GC) is imperfect and has major flaws

1.6 Disable unused variables and extra import

1.7 How to create an object too much to be tangled

1.8 object does not have constructors and destructors

The semantic setting of 1.9 defer statement is not very reasonable

1.10 Many language built-in facilities do not support user-defined types

1.11 No generic support, common data type interface ugly

1.12 Implementing interfaces does not require explicit declaration

1.13 Omit parentheses but save curly braces

1.14 compilation generated executable file size is very large

1.15 Dynamic load class library not supported

1.16 Other

• Methods and function overloads are not supported (overload)
• Import of PKG Imports statement the back part is text (import "FMT")
• Without enum types, global constants are difficult to classify, and iota complicate simple things.
• When defining an object method, the receiver type should be either a pointer or a non-pointer.
• The syntax for defining structs and interfaces is slightly more complex, interface XXX{} struct YYY{} isn't it more concise? The front plus type keyword looks wordy.
• There is no assertequal function in the test class library testing, and the standard library is flooded with unit test code if a != b { t.Fatal(...) } .
• Language is too simple to give up a lot of useful features, "Keep the language simple" is often a reason to refuse to improve.
• The implementation of the standard library is generally not ideal, its code quality is probably in the "Basic available" degree, real to enterprise-level application areas, often exposed many shortcomings.
• Version has grown to 1.2, the Goroutine Scheduler still uses only one system thread by default. The long-term presence of gomaxprocs seems to imply that officials have never had enough confidence to allow the scheduler to operate correctly and safely in multicore environments. This is a fatal contradiction to the localization of the go language itself with the concurrency as its core. (It didn't change until the second half of 2015 was released 1.5)
• The official release contains an auxiliary program called Oracle, which has nothing to do with the Oracle database, but completely ignores the name confusion between the two.

Read "Why I give up go language"