It's nice for languages to have a "benevolent dictator", but Go insists in a lot of arbitrary but not that good choices like the above.
I would add the bizarro build system (go build et al), that if you want to use you have to follow some rather silly conventions (a little flexibility would go a long way).
The GC also leaves a lot to be desired --they will implement something better eventually, but why wasn't that a top priority in 2012 for a "server systems" language? On 32 bits you are mostly toast with OOM errors, but even on 64 bit the GC is simplistic compared to most modern languages. YouTube, for example, had to jump through several hoops with memory issues to use Go in front of MySQL.
And, while the results are faster than Python/Ruby, they are not that competitive with C/C++ or even Java. The "20% slower than C" claim that you'll read is mostly BS. YMMV.
It doesn't help that if anybody brings up those issues, the general sentiment from the Go community (lists, etc) is also: "you're doing it wrong, reverse course, Go is perfect".
That said, I like Go, if it improves a bit with a 2.0 version, it can go places...
Go language has no syntactic difference between owning and non-owning pointers. Therefore, it is impossible to replace stop-the-world GC with reference counting GC eventually. IMHO that's a flaw in the language design and it's too late to fix it, this train is gone.
Nevertheless, we have other good ideas in programming language design these days. Vala, for example, has robust memory management (so it will have predictable memory use on heavily loaded web or db server), and also "async" methods and "yield" statement (borrowed from Python/C#), which effectively turns a function into a class with locals and instruction pointer converted to fields. That way, function execution can be interrupted and restarted at any moment (e.g. HTTP request handler waiting for database to respond).
Channels, coroutines and cactus stack in Go are great, but there are other worthwhile appoarches to solve C10K problem, and who knowns, maybe yield and async over traditional linear stack is better?
It's nice for languages to have a "benevolent dictator", but Go insists in a lot of arbitrary but not that good choices like the above.
I would add the bizarro build system (go build et al), that if you want to use you have to follow some rather silly conventions (a little flexibility would go a long way).
The GC also leaves a lot to be desired --they will implement something better eventually, but why wasn't that a top priority in 2012 for a "server systems" language? On 32 bits you are mostly toast with OOM errors, but even on 64 bit the GC is simplistic compared to most modern languages. YouTube, for example, had to jump through several hoops with memory issues to use Go in front of MySQL.
And, while the results are faster than Python/Ruby, they are not that competitive with C/C++ or even Java. The "20% slower than C" claim that you'll read is mostly BS. YMMV.
It doesn't help that if anybody brings up those issues, the general sentiment from the Go community (lists, etc) is also: "you're doing it wrong, reverse course, Go is perfect".
That said, I like Go, if it improves a bit with a 2.0 version, it can go places...