1. Go doesn't discard the last 40+ years of programming history. Ints, chars, arrays, pointers, structs -- in addition to minimalist types that build on these -- are at the heart of Go's lexicon.
2. Following off of point 1: C and C++ source code and algorithms are easily translatable into Go because they look like Go.
3. Following off of point 2: Because old C/C++ code looks similar to Go, Go's libraries will soon number C/C++.
4. A well thought-out, minimalist toolchain. Working with "go install", vim, and gocode is like dancing in the clouds when compared with the morass that is Eclipse or Visual Studio, let alone C/C++ and its makefiles.
5. Go's object-orientation is done right. Go strongly emphasizes "has-a" relations and eschews the "is-a" relations that are prevalent in C# and Java. To see the effect this has on code readability, look at Go's documentation. For example, http://golang.org/pkg/database/sql/ ...scanning one page tells one all that's needs to be known about a package. Go's objects ride just above atomic data structures. There is not a five-mile chain of object dependencies and corresponding taxonomy clouding one's understanding as in C# or Java.
6. Go's channels give the programmer their very own ksh/bash built right in to the language. Admittedly, this is an oversimplification, but piping program units together is a proven method of strongly modularizing applications and has the added benefit of being inherently concurrent. Languages have been moving away from the shell for decades and have in the process lost its advantages.
(With all that said in point 6, there is still room for something like a lightweight, cross-platform, glue-language similar to bash/ksh that -- like Go -- does not throw out 40+ years of shell history. Unsung Tcl/Tk (http://www.softpanorama.org/Scripting/tcl.shtml) and Expect seems to fit the bill the closest currently, though it does not read like the C family of languages. Perhaps if someone were to build a Go shell, or create a cshell that used used Go's conventions, Go would have a good glue-language counterpart.)
As for the other two links Go fanboys like to throw them around to feel happy that they beloved language is comparable to programming languages developed in the 70's.
Ignoring and being selective are different things. The golang designers have made intentional choices and the reasoning is provided in the links I sent. I am not a fanboy. IMHO, Go would have been MUCH more interesting if goroutines did not run in a shared address space and if they implemented generics (even as a hygenic macro..)
The things that you left off your list that I think are much more interesting are:
- Weak/Strong purity, enforced by the type system
- uniqueness typing
- chan is too special. The difficulty with implementing a good netchan interface is starting to show this.
1. Go doesn't discard the last 40+ years of programming history. Ints, chars, arrays, pointers, structs -- in addition to minimalist types that build on these -- are at the heart of Go's lexicon.
2. Following off of point 1: C and C++ source code and algorithms are easily translatable into Go because they look like Go.
3. Following off of point 2: Because old C/C++ code looks similar to Go, Go's libraries will soon number C/C++.
4. A well thought-out, minimalist toolchain. Working with "go install", vim, and gocode is like dancing in the clouds when compared with the morass that is Eclipse or Visual Studio, let alone C/C++ and its makefiles.
5. Go's object-orientation is done right. Go strongly emphasizes "has-a" relations and eschews the "is-a" relations that are prevalent in C# and Java. To see the effect this has on code readability, look at Go's documentation. For example, http://golang.org/pkg/database/sql/ ...scanning one page tells one all that's needs to be known about a package. Go's objects ride just above atomic data structures. There is not a five-mile chain of object dependencies and corresponding taxonomy clouding one's understanding as in C# or Java.
6. Go's channels give the programmer their very own ksh/bash built right in to the language. Admittedly, this is an oversimplification, but piping program units together is a proven method of strongly modularizing applications and has the added benefit of being inherently concurrent. Languages have been moving away from the shell for decades and have in the process lost its advantages.
(With all that said in point 6, there is still room for something like a lightweight, cross-platform, glue-language similar to bash/ksh that -- like Go -- does not throw out 40+ years of shell history. Unsung Tcl/Tk (http://www.softpanorama.org/Scripting/tcl.shtml) and Expect seems to fit the bill the closest currently, though it does not read like the C family of languages. Perhaps if someone were to build a Go shell, or create a cshell that used used Go's conventions, Go would have a good glue-language counterpart.)