No thanks.

You seem to be referring to the problem where (since the address space on 32-bit machines is small) some values may be identified as valid pointers. But that isn't the only problem with the garbage collector. It performs badly when lots of short-lived small objects are created. Eventually, it'll need a better collector.

> They are looking at improving it, but it will take time.

That's the standard answer. But currently, its GC is weak.

> A lot of the languages Go is often compared to, like Python, have far worse GC (CPython _still_ can't collect datastructures which have cycles, if any of them has a finalizer).

Here, the discussion was about Java and C#.

> As far as error handling goes, the designers of Go thought about it for a long time. You may or may not agree, but calling it "contrived" is disingenuous. Basically, a lot of people have used and grown to dislike the confusion of routine errors and exceptions that prevails in languages like Java.

Every serious chunk of Go code is interwoven with if statements to check for errors. It breaks the logical flow of functions. Besides that, it's not mandatory to bind the return values of a function. So for side-effecting functions, it's easy to accidentally ignore errors. And then there is the whole 'nil may equal be nil' issue:

http://golang.org/doc/go_faq.html#nil_error

> You want exceptions only for signalling fatal errors.

I want errors as values, *without* having to check the result of every function call. This has long been solved in option types that are also monads, see e.g. Maybe and Either in Haskell. Java checked exceptions are not too bad either: they don't clutter the flow, but you cannot silently ignore them (you have to catch them or indicate that your method might throw that particular exception).

Go doesn't differ much from C wrt. to error handling. Except that in C I know that -1 is always -1 or 0 is always 0.

> Both are perfectly valid approaches. I don't feel like the colleciton of macro tricks and templates often glorified as "a DSL" in C++ requires any comment, other than: please, make it stop.

Right, I was referring to the latter (EDSLs). So, what facilities does Go provide to support the latter? I haven't seen any real EDSL in Go. DSLs have been done in static languages before, without the horror of C++. E.g. Hamlet is a EDSL in Haskell for producing HTML in a type-safe manner:

http://www.yesodweb.com/book/shakespearean-templates

Hakyll is an EDSL for constructing static site generators:

http://jaspervdj.be/hakyll/index.html

> With regard to generics: if you find yourself using interface{} everywhere, you're doing something wrong.

Sorry, I was being sarcastic there. It's the standard answer you will get on various Go fora: Go doesn't need generics, because there is interface{}. Anyway, the criticism still stands: Go doesn't have parametric polymorphism, so you either:

- If you are lucky, use non-empty interfaces.
- End up duplicating copying the same algorithm multiple times for different types.
- Write functions that take the empty interface and return the empty interface.

E.g. consider writing the Haskell function:

replicate :: Int -> a -> [a]

(Repeat a value n times.)

A Go equivalent is:

func replicate(n int, val interface{}) []interface{}

Not only does this completely throw away type safety, it's also an example of Go's tediousness. If you call, say replicate(20, 10), you cannot directly cast the result to an []int, because []interface{} is obviously something different.

By all means, don't take my word for it. I encourage people to read Mark Summerfield's Programming in Go. If you use a modern static language such as C#, Haskell, or whatever on a daily basis, you'll be thinking "heh, I could do this in X more elegantly in a far smaller number of lines" every half page or so.

The only great feature of Go is gofmt.