> I would not write a wiki app in it, but certainly the next Apache or Nginx replacement.
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++.
Actually Go GC is quite easy to control. If you know your butt from your elbow you can write code that doesn't GC at all.
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.
> Its easier to optimise a GC than to fix memory and reference counting bugs.
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 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++.