4 ms·

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

by camus2 9y ago

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

ChickeNES 9y ago
>There is a reason why some gophers are working on an actual package manager... Finally! I had to deal with a golang project once, the dependency management made me want to pull my hair out after using Bundler and Cargo
- ajmurmann 9y ago
  Yes! Once you've used Bundler and Cargo anything else seems just silly and unacceptable.
regecks 9y ago
> 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 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.
- pmilot 9y ago
  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.

by camus2 9y ago

ChickeNES 9y ago

>There is a reason why some gophers are working on an actual package manager... Finally! I had to deal with a golang project once, the dependency management made me want to pull my hair out after using Bundler and Cargo

ajmurmann 9y ago
Yes! Once you've used Bundler and Cargo anything else seems just silly and unacceptable.

regecks 9y ago

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

pmilot 9y ago
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.