For about two years, many of the people I work with have been using Go almost exclusively because, while simple and fast like C, the things it adds are so useful we can't imagine trying to hack similar functionality together with C libraries. Things like built-in maps, slices, multiple returns, lambda functions, channels, goroutines... these are all things you can accomplish in C, but it's so much more painful (see: homebrewed hashtables, do-it-yourself pointer management on a big array, returning structs, function pointers, some sort of mutex abomination to replicate channels, pthreads)
And although I haven't tried it out myself yet, it does seem very promising for such use cases. You don't have to "give up" 30 years of existing C code if you are just using it as libraries and OS calls, not rewriting it.
I wouldn't. Nondeterministic garbage collection in a web server like nginx (as opposed to an application web server like Jetty) makes me very nervous. The HTTP (or pick-your-other-TCP-protocol) lifecycle is well-understood enough that you should be able to handle your own memory management.
There are lots of things in Go I like, but for me they're coupled with questionable abstractions that make it difficult to rationalize over C++.
I really don't have a problem with GC though. Its easier to optimise a GC than to fix memory and reference counting bugs. Memory management is not a problem I want to be dealing with after 60-odd years of computers being around.
I don't agree. If you are competent enough to be needing to write your own web server, memory management should be utterly trivial.
There are many use cases where you do not need to really balance bleeding performance against programmer conveniences. Something like "Apache or nginx" is without question one of them.
I do have a side project of writing a DNS server, and my scribbled notes for it say to use Erlang for the protocol speaker and Go for the control plane.
I suggest that what Go needs is some kind of killer project that everyone can learn from. C had UNIX.
Goroutines and channels in particular are an interesting and useful abstraction away from threads and communication between those threads.
Linus Torvalds would disagree that C and C++ are the same language as suggested by "C/C++" and by the singular pronoun that follows.
http://harmful.cat-v.org/software/c++/linus
And maybe too much weight is given to Torvalds' views on this and other topics.
One can easily program as if it were C, using templates to avoid ugly macro mess for generic algorithms and types.
Edit: corrected is -> as.
Did you mean "as if"? If so, that's exactly what Torvalds objects to -- the things about C++ that supposedly represent improvements over C. He goes on about how many of the conveniences of C++ -- like the STL -- aren't as wrung out as most people think and don't actually work as intended.
I don't necessarily agree with his position in all respects, but some of the enhancements in C++, aren't actually enhancements.
Feel free to correct me if I'm wrong.
Go exists, the runtime and the compiler is written in C and from what I've read from Russ Cox there are no plans whatsoever of rewriting either in Go.