My Opinionated Guide To Go

I’d posit that 90+% of apps don’t need another http server. Big apps have good reasons for a dedicated http server – unifying SSL termination, load balancing – but they are a minority.

There is nothing to to prevent you from putting nginx in front of the Go app if that’s better.

Go forbids importing modules that you then don't use in the source code. This is particularly annoying with the "fmt" module, which contains things like Printf that are useful for debugging, but you may only be using fmt.Printf for one debugging statement in the code. Consequently, if you're developing, and you're adding and removing it over and over you also have to add and remove it to and from your import list over and over, which is very annoying since it's likely to be relatively distant from your use location, and it's mandatory that all imports are listed at the top of the file. (So, you can't do what you can do in perl and say "use Data::Dumper; print Dumper($debugging_stuff);" all on one line, without even being concerned about whether Dumper may already be imported.)

goimports is a source filter that cleans out any unused modules, and tries its best to add modules that you only reference. It's pretty good. You can confuse it if you have two modules with the same last bit of the name, but the standard library doesn't have that anyhow, and for the most part you can deal with that. Since it also runs gofmt for you on save, it's also a drop-in replacement for gofmt, which you should configure your editor to run on every save even if you for some reason don't want the goimports functionality. (Seriously. Just do it. There's no excuse not to. There's no excuse to ever commit code that was not gofmt'ed.)

If you do that, the problem goes away. Typing "fmt.Printf" pulls fmt in automatically, removing the one line removes it automatically, the import list is always accurate, and it's smart enough that if it isn't the only usage it doesn't remove it.

That said, I also strongly recommend setting up automatic syntax checking by compilation (flymake in emacs, don't know what in vim, etc), so that you also avoid the "Save -> switch windows to terminal -> compile -> get smacked in face with an error that feels stupidly persnickety" psychological torture. If the errors highlight in your editor on save or something, you go through that much less. Those who lived in the C#/Java etc world have long had this... a lot of people coming from the scripting side would be advised to pick up a bit more of the helpful tools the static side has to offer.

Is there any reason to use RVM, PVM on production while Go does not required one?

I believe should be install one and only one Ruby/Python version on production.

Why Ruby/Python does not required application server like unicorn/wcgi, etc?

The article clearly try to make other deployment more complicated.

The languages you are citing are slow enough that the scripting language would like to slice away as much of the brute web serving load as possible so the slow scripting language can concentrate its power on the real task at hand.

Go is more on the compiled side. It's not C-fast quite yet (I expect it to eventually converge somewhere around 1.5x as fast, it's not quite there yet), but currently around 2-3x slower only (and net/http is seeing a lot of direct work on it, it's quite fast now). You don't get the big win that you get with letting nginx handle the brute string manipulation of HTTP and prechewing on it for the 20-100x slower scripting language.

Also, remember that you can view HTTP itself as a form of CGI request... really, FastCGI etc. doesn't do anything that an already very multi-threading-friendly language can't do with straight HTTP. Those standards are solving a lot of problems that Go just doesn't have, and straight HTTP is actually more general and flexible if you can afford it (no problems with Nginx being unable to stream FastCGI, etc).