[paukiatwee]

"Go: Code -> Operating System -> Hardware"

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.

[treystout]

A lot of python shops I've come across don't use the system installed python or ruby. In python land at least it's exceedingly common to deploy a virtualenv with a separate python runtime and isolated 3rd party libs. This makes pinning your version deps easier and doesn't matter if the underlying server is ubuntu or centos or whatever.

[paukiatwee]

That is true, what if in future ubuntu/centos include Go by default (which might not the version you use)? I believe then will have some GVM or similar tool to solve the problem.

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.

[Supermighty]

There won't be a need for a GVM as Go is not a stand-alone runtime. Once compiled for a specific platform it will just run. You don't even need it installed on the server. You can cross-compile on your DEV machine and move the binary LIVE. Then it just runs. It doesn't need any libraries on the server.

[kasey_junk]

Does Go not have the concept of linking? If you are deploying several Go applications on the same server that each use libraries, does it include duplication of libraries in every binary?

[Supermighty]

There is no linking. Each Go binary has all of the libraries it needs baked into it.

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.

[NateDad]

All Go applications are statically linked. There are no libraries. It's a single executable that you can copy to your target machine and run.

[NateDad]

Go applications require no installed runtime, they compile to native code. You can have no Go installed or any Go installed on the system, and the executable will neither know nor care.

[kasey_junk]

Not being a Go developer I don't understand why this would be the case. Doesn't Go compile code to a binary? Why should Go even be required on the server?

[NateDad]

Yeah, many of the ruby applications I've seen recommend RVM so that you can isolate yourself from the system-installed version of ruby. That's the nice thing about go - each application carries around everything it needs to run in total isolation from the rest of the machine.

[icebraining]

Except for libc, of course.

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...

[NateDad]

I should just stop making assumptions about python and assume that if there's anything you ever would like to do with python, that someone has already built it :)

[microtonal]

It's a nonsense comparison anyway. E.g. with Java I don't have to care much about the hardware an operating system (e.g. we develop on Mac and deploy on Linux).

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...

[lateefj]

Not sure I follow? With Go we develop on Mac and deploy on Linux. Just change the environment variable. Linux has some great built in tools for "security management".

[microtonal]

You have to recompile for another platform. There may also be subtle differences in the platforms.

[NateDad]

There are some subtle differences.... but these would likely be exposed in almost any language with or without a VM. For example, when porting some of our Linux Go code to Windows, we realized we were renaming a file while we held the file handle open. That works fine on Linux, and blows up on Windows. That's not really something a VM can manage for you. Similar things like "what's the canonical directory for storing your ssh configuration" is different per OS, and again, is not likely to be something that the VM will sort out for you.

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.

[herge]

One version of python on a modern linux OS? How do you mesh the default version of python used by the os with the version of python required by your application code?

[regularfry]

There's no reason to do it, but people do.