My Opinionated Guide To Go
blog.hackingthought.com
blog.hackingthought.com
I mention this because the article acts as if getting rid of abstraction layers between the OS and the code is a new idea. No, that's how all compiled languages are... that's the point of compiled languages. I suppose Go's most common use case lines it up against a bunch of slow interpreted languages, but really there's no reason except good libraries that you can't use the other compiled languages I mentioned for web apps.
Go advocacy tends to ignore what other modular languages with native compilers offer since the early 80's, as well as, present a cut down version of what modern runtimes are capable of.
When you look at the people coming to Go, most are coming from Python or Ruby, not C, C++, or Java. So a lot of the experience Go developers have are those other languages. As Rob Pike pointed out 2 years ago[1], while they set out for Go to replace C++, it ended up actually being a much better fit for Python and Ruby developers.
[0] http://adventgo.blogspot.ca/2014/05/origin-of-go-toolchain.h...
[1] http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
I would imagine it's similar for the java guys, especially now that there's java 8, you start having to worry whether it's installed etc. I think Java is a harder sell, because most Java guys don't recognize the complexity inherent in their huge type systems, and they have all these new toys to play with in Java 8 without having to learn a whole new language.... I think they'll come around eventually, though.
Go happens to also be a really great alternative to C and C++ (at least in applications where you don't need the strict timing of a GC-less language...) It's much less error prone than C and C++, with memory safety making most truly critical security bugs simply impossible. Again, like the Java guys, it's a little hard to convince people that have been working in the language for 15-20+ years that there's something that can make their lives easier...
So, I really didn't mean to denigrate any communities or languages, there's definitely nothing intrinsically wrong with Java, and the ecosystem is at least an order of magnitude larger than the one for Go. Java guys have probably the least reason to switch to Go of all the languages I mentioned. I can certainly understand why a Java dev would look at Go and wonder why anyone would ever choose it over Java.
Go isn't likely to beat many languages on features, since it was purposely designed to have fewer features than most other languages. I do think it offers some advantages over Java, but Java also offers some advantages over Go. It's not a contest. No one has to "win". There's a time and a place for nearly every language.
However I find both your answers quite faire.
My pet peeve is more with younger developers that promote Go vs other languages, without knowing how rich they actually are. Or the alternatives that came before, lost in the mist of time, with similar features.
Nowadays I do find that Go is a good and safer alternative, for C programmers doing applications that can live with a GC.
For other backgrounds in languages with native compilers available, I guess we have to agree to disagree. :)
You mean, like Java and C# ?!
That even leaves out Java compilers that skip the JVM step.
I am one of them - have used (and still use) Python since v1.52, but found Go an excellent option when performance / concurrency was needed.
Maybe that'll be a non-issue the more I use Go, but so far it's a bit of a time waster.
For sublime users, see here: http://michaelwhatcott.com/gosublime-goimports/
It's a great tool, very convenient.
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.
Edit: As others pointed out, Go is compiled binary and does not required runtime (like JVM) so versionning is not issue. Thanks for clearing up.
So if you have multiple different Go applications on one server, and they use some of the same libraries, then each application's binary will contain a copy of that library.
It makes things a little redundant, but also simplifies the deployment process.
edit: The only exception is if you are using cgo and liking to existing C libraries. In pure Go there is no linking.
By the way, you can actually do the same for Python using cx_Freeze; it'll create a single executable with Python + libraries + you code.
[1] http://cx-freeze.readthedocs.org/en/latest/script.html#scrip...
And sure, you can use an application container. But you can also embed a webserver. E.g., we Jetty embedded and use a strict SecurityManager policy[1]. So it's more like:
Code -> JVM (with security manager)
[1] http://docs.oracle.com/javase/tutorial/essential/environment...
I'm in the middle of porting Juju, a pretty huge Go program, from linux to linux and windows, and almost all the changes necessary are not things that a VM can help with, like "cloud init doesn't exist on windows" and "unix pipes don't exist on windows" etc.
For everything else, the Go runtime really does a pretty good job of abstracting away the differences.
Why does the de facto standard for web apps in Go-land seem to be using the built-in HTTP server provided by net/http, or otherwise having the program server as its own HTTP server?
Most other languages seem to have converged on FastCGI or some similar model ({W,P}SGI, Rack, etc.).
It irks me a bit because I don't understand why you'd want to do it this way; it seems preferable to have a dedicated HTTP server in pretty much every way I can think of.
Does anyone have any insight there?
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.
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).
That said, it's an advantage of heterogeneity; you get some security by being a small target in a sea of OpenSSL servers.
This makes no sense. The runtime of Docker is the Operating System. There's no extra layer, as it's being implied.
And there's no difference between Go and the other languages that makes Docker more or less useful. You can have separate Python processes without Docker, just like you'd have separate Go processes.
I like Go, but this article just sets up strawmen to bring down.
Which framework is the best? Why are there so many? Which is the easiest for my specific goals? An opinionated guide that said something like "Use Flask because X" or "Use Django because Y" would have been pretty useful.