I have been tinkering with Go for a couple months and I've been so impressed with it I'm about to start a real production server using it. It has all the low-level functionality of C with some very useful features added, like garbage collection, string manipulation, new data types like slices and channels, and of course threading.
The main downside is that there are not a lot of libraries available. If you want to use the language you will find yourself using 3rd party wrappers off github of unknown quality, and you will probably have to wrap some C libraries yourself, because no one else has.
Also, both the garbage collection and the goroutine scheduler could use some work. Like most other garbage-collected languages, Go's GC has to stop all threads in the program while it does its work, causing milliseconds of lag. This makes the language unsuitable for realtime work like a fast-paced video game.
The goroutine scheduler works using a fixed-size thread pool. You have to tell it how many threads to use - by default programs are single-threaded. It has no ability to lower the thread count when the system is under heavy load, or to raise the thread count when most threads are unproductively waiting on network IO.
Despite these minor problems it is amazingly full-featured for a compiled language, and amazingly fast for a full-featured language. They are actively working on improving the garbage collection and they plan to improve the thread scheduler.
I will just note that improvements to the GC and scheduler and other compiler optimizations are already implemented and will be part of Go 1.1
Also, the Go stdlib is very rich and covers lots of stuff, I have rarely found need for bindings to C libs unless it is OpenGL.
Which brings me to the point of games, there are already a couple of games using Go, the GC pauses are not as big of an issue because the GC is good enough (it is parallel) and in Go is easy to avoid generating garbage.
If I had to guess, it's because people are quite excited about the language and they're interested in giving it some visibility. There's always lots of new technologies, but very few gain wide adoption.
It's more of a "best practices" than it is documentation. In the vein of Effective C++ by Scott Meyers. It's well-written, informative and interesting. Definitely one of the best resources on Go I've come across.
There is a collection programming books titled "Effective X", for language X. From multiple publishers, IIRC, though I think it may have started with Addison Wesley.
The majority of those books with which I'm familiar have pretty good if not excellent reputations.
I would suggest that this documentation's title may be acknowledging this, and perhaps -- deliberately or not -- leveraging it.
EDIT: No, maybe it was indeed O'Reilly. E.g. Effective C and Effective C++.
Any idea why Go uses tabs for formatting? (A google search didn't provide the answer but did suggest I may want to find out why God does!)
About the only good pro-tab stance I have seen is that it allows the viewer to choose a level they prefer, but I would expect consistency would be far better.
That was actually one of the questions asked during the "Meet the Go team" talk at Google I/O. They joke around for a bit, but they end up giving some solid arguments.
The answer given was that individuals can then choose how many spaces they want their tabstops set to, and this was mostly an accident not formal thought out design. (I didn't see any other arguments given.) gofmt itself is of course a very good idea.
I have been following Go along the years, but think they made a big mistake with exceptions. In particular you have to manually write the code from where an issue happens all the way to where it is handled. Exceptions as done in other languages isn't the exact pattern that has to be followed - it is the writing of the boilerplate code that bugs me. Heck they could do something as simple as if the error value returned is not used in any way then an automatic 'return ...vals..., error' is inserted after the call.
Thanks for the links, and panic is the usual retort. My problem is with the boilerplate between methods. If A calls B calls C calls D calls E which can have issues that A wants to handle (eg try a different IP address) then all the intermediary functions will need code like:
foo,bar,err=callX(...)
if err!=nil:
return _,_,err
It is the last two lines of boilerplate that need to be present for virtually every call that makes me uncomfortable. Developers will start forgetting or not being diligent which causes problems. Also I think (but don't know) that by the time A gets an Error it won't know what the stack trace is for the original Error. (The stack traces are extremely useful for logging and analytics not for program behaviour.)
Needing to write the boilerplate means it is left out. For example look at all the hello world examples. Note how they all ignore any errors from the println. C has exactly the same problem, and I'm disappointed that Go is perpetuating this problem.
Go doesn't require tabs. Tabs and spaces work just like C, they separate tokens but are not otherwise relevant. It's not like Python where they indicate indentation level.
The only whitespace character that works differently than C is the newline. In Go, newlines (usually) separate statements, like a semicolon does in C.
Code formatting conformity is pretty big in the Go culture.
Go the language doesn't care if you use tabs or spaces, Go the community would prefer you to use tabs so when your Go code is loaded in whatever random editor any member of the community uses there are no surprises.
The Go language seems to have some substantial documentation, which is great. Though, throughout, the code snippets would look better with some syntax highlighting.
The main downside is that there are not a lot of libraries available. If you want to use the language you will find yourself using 3rd party wrappers off github of unknown quality, and you will probably have to wrap some C libraries yourself, because no one else has.
Also, both the garbage collection and the goroutine scheduler could use some work. Like most other garbage-collected languages, Go's GC has to stop all threads in the program while it does its work, causing milliseconds of lag. This makes the language unsuitable for realtime work like a fast-paced video game.
The goroutine scheduler works using a fixed-size thread pool. You have to tell it how many threads to use - by default programs are single-threaded. It has no ability to lower the thread count when the system is under heavy load, or to raise the thread count when most threads are unproductively waiting on network IO.
Despite these minor problems it is amazingly full-featured for a compiled language, and amazingly fast for a full-featured language. They are actively working on improving the garbage collection and they plan to improve the thread scheduler.