Effective Go
golang.org
golang.org
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.
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.
1) Let's say you want to do everything you can to avoid generating garbage. What would some those techniques be?
2) There is no delete function is there (for memory deallocation, not hashmap key removal)?
3) Is it possible to eliminate all garbage, and if so could you prevent the GC from starting up at all?
Possible existing answers that are a bit above my understanding (C# and Python spoil me):
http://news.ycombinator.com/item?id=4231048
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++.
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.
The only whitespace character that works differently than C is the newline. In Go, newlines (usually) separate statements, like a semicolon does in C.
We use tabs for indentation and gofmt emits them by default. Use spaces only if you must
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.
http://www.youtube.com/watch?v=sln-gJaURzk&feature=playe...
Edit: If you're curious/interested in Go, it's worth watching the whole talk.
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.
https://code.google.com/p/go-wiki/wiki/PanicAndRecover
foo,bar,err=callX(...)
if err!=nil:
return _,_,err
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.