> Go also doesn't have the problem of conflicting system level packages.
Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others.
> Go doesn't have to deal with interpreter dependencies
As long as Go is forward compatible this will old true, but I don't think this was the point of the comment.
'go get' is a half-baked package manager and yes it fetch packages and resolve dependencies between packages so that's a package manager. It just doesn't care about versions. Other languages have solved the issue by requiring a third party tool, Ruby even has its own build tool.
There is a reason why some gophers are working on an actual package manager...
> Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others.
Not even then, to be honest.
I wrote a product that is deployed on many thousands of servers, and all of a sudden a not-insignificant population just started experiencing SIGABRTs on process start.
Turns out Amazon Linux (and some others) had removed a syscall that i386 Go on Linux was relying on (https://github.com/golang/go/issues/14795). We built our product with a manual patch against "src/runtime/sys_linux_386.s" for many months as a result, and it was really a huge headache to help all our customers.
I would be surprised if Python or even Java broke in this way, for example. I was really surprised it even happened in Go to be honest.
There are other runtime problems too, we had a weird interaction with a "cloud OS" based on cgroups (CloudLinux) screwing up our Go processes depending on how many goroutines we ran ...
I think Go is fantastic but its runtime can definitely clash with its environment ... it's not the same as a C program.
Was the system call part of POSIX or the standard Linux interface? Because if so, that sounds like the fault belongs to Amazon, not Go. The same thing could happen to the Python interpreter.
Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others.
> Go doesn't have to deal with interpreter dependencies
As long as Go is forward compatible this will old true, but I don't think this was the point of the comment.
'go get' is a half-baked package manager and yes it fetch packages and resolve dependencies between packages so that's a package manager. It just doesn't care about versions. Other languages have solved the issue by requiring a third party tool, Ruby even has its own build tool.
There is a reason why some gophers are working on an actual package manager...