From C-Chimpanzees to Go-Gopher, Google hopes to remake programming with GoThere is a ne iconic mascot over there, born out of habit of enraged apes of flinging their own feces at their object of anger when they fail to catch nuts because their C language sucks (if you haven't experienced this phenomenon first hand consider yourself blessed). A new specie has come, it's a Go- Gopher, smart enough to be able to grow their acorns.
(my humor
)
Go-pher, iconic mascot, referred to
golang, a programming language developed at
Google in 2007
"
The Go Programming Language",
Specification,
FAQBorn out of frustration with existing languages and environments for systems (also embedded?) programming when programming had become too difficult, no doubt Google's Go language is off to a great start, but still has work ahead: Go offers speed, concurrence, and portability, but it's still young and might be too simple, it's currently fully supported on
Linux and
Darwin/MacOSX and fully integrated in Gcc >=gcc-v4.9(1) as "frontend" connected to the GCC backend. This means that, in the Theory(2), any
Go program that you can compile for
x86/x86_64 should work on Arm, and besides
Linux and
Darwin/MacOSX,
Go is also "experimentally supported" on
FreeBSD and
NetBSD, Go is a new language. Although it borrows ideas from existing languages, it has unusual properties that make effective Go programs different in character from programs written in its relatives. A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go. On the other hand, thinking about the problem from a Go perspective could produce a successful but quite different program. In other words, to write Go well, it's important to understand its properties and idioms.
I put emphasis in the above presentation to catch your attention, I'd like to hear some unbiased opinions about (1) you can try to compile gcc with
./configure --languages=C,Go
(2) It seems that the Go team has written two different compilers that implement that spec:
- gc, the first one, is the original compiler, and the go tool uses it by default, I guess that having two different implementations helps ensure that the spec is complete and correct: when the compilers disagree, they fix the spec, and change one or both compilers accordingly, It supports only the most popular processors: x86 (32-bit and 64-bit) and ARM
- gccgo, slower than gc but it supports all the processors that GCC supports. Not all those processors have been thoroughly tested for gccgo, but many have, including { x86/32bit, x86/64bit, SPARC, MIPS, PowerPC }. Gccgo has also been tested on operating systems that the gc compiler does not support, notably Solaris (what about Irix? Aix? who knows?)