6 ms·

> Python, Node and Ruby all have better systems for package management Maybe they have better tools for managing package dependencies but Go doesn't have to de

> Python, Node and Ruby all have better systems for package management Maybe they have better tools for managing package dependencies but Go doesn't have to deal with interpreter dependencies, which can be a major headache. Go also doesn't have the problem of conflicting system level packages. Honestly no matter how good your deployment practices are, if you have to manage an application's deployment long term you're going to have dependency problems of some kind. I'd rather deal with those problems at compile time than hit an edge case during deploy or in prod.

tomohawk 9y ago
This has been a massive win for us vs languages that require you to haul around a runtime and other dependencies.
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.
disconnected 9y ago
> conflicting system level packages In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages. If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.
- foota 9y ago
  Solved as long as there aren't native dependencies not managed by pip, which there often are.
  - joshuamorton 9y ago
    Wheels solved this problem in 2013. For context, you can install opencv, tensorflow, ROS, matplotlib, and the entire scipy stack in a virtualenv, with no external dependencies, using wheels. This means that you can generate images, train a machine learning algorithm on them, compare the results to conventional CV algorithms, and display them in an ipython notebook all from a venv. There's a huge amount of C++ and even qt integration in that pipeline, all isolated. It won't be maximally performant (ie for massive training), but for that you'd want distributed docker deploys or similar anyway.
    - sethammons 9y ago
      Wheels just broke something in our build pipeline. They removed support for Python 2.6 and started tossing errors. I was able to fix it by pinning Wheel which probably should have been done originally by who ever made the build utility, but it would have been a non issue with Go and a binary.
      - joshuamorton 9y ago
        Well, python 2.6 was also EoL'd 4 years ago, so yes, if you're using a no longer supported piece of software and not pinning your versions, I'd argue that you're inviting issues.
tootie 9y ago
Just use Java.

tomohawk 9y ago

This has been a massive win for us vs languages that require you to haul around a runtime and other dependencies.

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.

disconnected 9y ago

> conflicting system level packages In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages. If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.

foota 9y ago
Solved as long as there aren't native dependencies not managed by pip, which there often are.
- joshuamorton 9y ago
  Wheels solved this problem in 2013. For context, you can install opencv, tensorflow, ROS, matplotlib, and the entire scipy stack in a virtualenv, with no external dependencies, using wheels. This means that you can generate images, train a machine learning algorithm on them, compare the results to conventional CV algorithms, and display them in an ipython notebook all from a venv. There's a huge amount of C++ and even qt integration in that pipeline, all isolated. It won't be maximally performant (ie for massive training), but for that you'd want distributed docker deploys or similar anyway.
  - sethammons 9y ago
    Wheels just broke something in our build pipeline. They removed support for Python 2.6 and started tossing errors. I was able to fix it by pinning Wheel which probably should have been done originally by who ever made the build utility, but it would have been a non issue with Go and a binary.
    - joshuamorton 9y ago
      Well, python 2.6 was also EoL'd 4 years ago, so yes, if you're using a no longer supported piece of software and not pinning your versions, I'd argue that you're inviting issues.

tootie 9y ago

Just use Java.