7 ms·

> same developer experience as go You can't say that when Python shoves Pip/Poetry/VirtualEnv/Black/Flake and what not into people. In contrast, Go has built-i

> same developer experience as go You can't say that when Python shoves Pip/Poetry/VirtualEnv/Black/Flake and what not into people. In contrast, Go has built-in package management and gofmt. Python is essentially gate-keeping new devs.

morelisp 7y ago
Go may be unique in being the only ecosystem built after Python that can't claim it avoided Python's packaging disasters.
- mdtusz 7y ago
  Cargo works pretty well too.
  - takeda 7y ago
    Cargo is not from Go
    - jessaustin 7y ago
      As a name for a package manager, "cargo" certainly appears more suitable for "go" than for "rust".
- takeda 7y ago
  I believe Python suffers from no leadership in that space (everyone creates their own packaging, every tutorial advocates something different, many tutorials are outright wrong). There was also a bad decision of using Python code for installation (setup.py) instead of a declarative language. Most of that issues are actually fixed in setuptools if you put all settings in setup.cfg and just call empty setup() in setup.py. Like here: https://github.com/takeda/example_python_project/blob/master/setup.cfg https://github.com/takeda/example_python_project/blob/master...
- throwaway894345 7y ago
  How do you figure? Go's packaging is wayyyy better than Python's. I've done considerable work with each and while Go's ecosystem has warts here and there, it's far from disastrous. I can't say that about Python. If nothing else, Go lets you distribute a static binary with everything built in, including the runtime. Python's closest analog is PEX files, but these don't include the runtime and often require you to have the right `.so` files installed on your system, and they also don't work with libraries that assume they are unpacked to the system packages directory or similar. In general, it also takes much longer to build a PEX file than to compile a Go project. Unfortunately, PEX files aren't even very common in the Python ecosystem.
  - morelisp 7y ago
    In the context of > Pip/Poetry/VirtualEnv "packaging" refers to the way the language manages dependencies during the build and import process, not how you distribute programs you have built. Python has a deservedly poor reputation here, having churned through dozen major overlapping different-but-not-really tools in my decade and a half using it. And even the most recent one is only about a year into wide adoption, so I wouldn't count on this being over. Go tried to ignore modules entirely, using the incredibly idiosyncratic GOPATH approach, got (I think) four major competing implementations within half as long, finally started converging, then Google blew a huge amount of political capital countermanding the community's decision. My experience with Go modules has been mostly positive, but there's no really major new idea in it that needed a decade to stew nor the amount of emotional energy. (MVS is nice but an incremental improvement over lockfiles, especially as go.sum ends up morally a lockfile anyway.)
    - throwaway894345 7y ago
      I fully agree with this assessment, but I don’t see how this puts Python’s story on par with Go’s. While GOPATH was certainly idiosyncratic, it generally just worked for me. While go modules aren’t perfect and the history was frustrating, they generally work fine for me. Python feels like an uphill battle by comparison.
sandGorgon 7y ago
Go has had an equally bad packaging experience. Kubernetes - which is one of the biggest projects built in go - has been struggling with dependency and package management. Here's the CTO of Rancher commenting on his struggles https://twitter.com/ibuildthecloud/status/1187529098886664193?s=19 https://twitter.com/ibuildthecloud/status/118752909888666419... https://twitter.com/ibuildthecloud/status/1187538210152308736?s=19 https://twitter.com/ibuildthecloud/status/118753821015230873... This is not trivial stuff..and it shouldn't be trivialised into a go vs python flamewar. Because it can't be.
- throwaway894345 7y ago
  I've used Python and Go extensively. Go's packaging story has a few rough edges, but Python's is an impenetrable maze of competing tools that each purport to address others' major hidden pitfalls. To work with Python packages, you have to pick the right subset of these technologies to work with, and you'll probably have to change course several times because all of them have major hidden pitfalls: * wheels * eggs * pex * shiv * setuptools * sdist * bdist * virtualenv * pipenv * pyenv * sys.path * pyproject.toml * pip * pipfile * poetry * twine * anaconda To work with Go: * Publish package (including documentation): git tag $VERSION && git push $VERSION * Add a dependency: add the import declaration in your file and `go build` * Distribution: Build a static binary for every target platform and send it to whomever. No need to have a special runtime (or version thereof) installed nor any kind of virtual environment nor any particular set of dependencies.
  - ForHackernews 7y ago
    Yeah, until github is unreachable and the entire Go universe grinds to an immediate halt because nothing will build. Python packaging is a mess, but Go doesn't even bother. "Just download from some VCS we'll pretend is 100% reliable and compile from source" is not a packaging solution.
    - kelnos 7y ago
      How is that any different than the entire Python universe grinding to an immediate halt if there's an issue with pypi.python.org? (Hint: it's not.) You can certainly debate the difference in uptime between specific services; I don't know either way, but if you told my that PyPi had higher uptime than GitHub, I'd believe you... but that's kinda missing the point. If you depend on an online service to host your release artifacts, if and when that service goes down, it's gonna hurt. Meanwhile, Python's packaging wars continue to rage on. Go's is simple: a release is a tag in a VCS repository. I'm sure there are issues with that as well, but that should come as no surprise, considering there are issues with literally every packaging solution. At any rate, there's little moral difference between downloading a tarball (or a wheel, or... whatever), vs. pulling a tag from a git repo. It requires equal levels of trust to believe that no one has tampered with prior releases in both cases. I'd like to also point out that I don't have a dog in this race. I've done a little Go here and there, but frankly I don't like the ergonomics of the language too much, so I stay away from it. I've done (and continue to do) a decent amount of Python. I like the language, but tend to prefer strongly-typed, functional languages, and languages with performant runtimes, so I tend to only use it for smaller projects.

morelisp 7y ago

Go may be unique in being the only ecosystem built after Python that can't claim it avoided Python's packaging disasters.

mdtusz 7y ago
Cargo works pretty well too.
- takeda 7y ago
  Cargo is not from Go
  - jessaustin 7y ago
    As a name for a package manager, "cargo" certainly appears more suitable for "go" than for "rust".
takeda 7y ago
I believe Python suffers from no leadership in that space (everyone creates their own packaging, every tutorial advocates something different, many tutorials are outright wrong). There was also a bad decision of using Python code for installation (setup.py) instead of a declarative language. Most of that issues are actually fixed in setuptools if you put all settings in setup.cfg and just call empty setup() in setup.py. Like here: https://github.com/takeda/example_python_project/blob/master/setup.cfg https://github.com/takeda/example_python_project/blob/master...
throwaway894345 7y ago
How do you figure? Go's packaging is wayyyy better than Python's. I've done considerable work with each and while Go's ecosystem has warts here and there, it's far from disastrous. I can't say that about Python. If nothing else, Go lets you distribute a static binary with everything built in, including the runtime. Python's closest analog is PEX files, but these don't include the runtime and often require you to have the right `.so` files installed on your system, and they also don't work with libraries that assume they are unpacked to the system packages directory or similar. In general, it also takes much longer to build a PEX file than to compile a Go project. Unfortunately, PEX files aren't even very common in the Python ecosystem.
- morelisp 7y ago
  In the context of > Pip/Poetry/VirtualEnv "packaging" refers to the way the language manages dependencies during the build and import process, not how you distribute programs you have built. Python has a deservedly poor reputation here, having churned through dozen major overlapping different-but-not-really tools in my decade and a half using it. And even the most recent one is only about a year into wide adoption, so I wouldn't count on this being over. Go tried to ignore modules entirely, using the incredibly idiosyncratic GOPATH approach, got (I think) four major competing implementations within half as long, finally started converging, then Google blew a huge amount of political capital countermanding the community's decision. My experience with Go modules has been mostly positive, but there's no really major new idea in it that needed a decade to stew nor the amount of emotional energy. (MVS is nice but an incremental improvement over lockfiles, especially as go.sum ends up morally a lockfile anyway.)
  - throwaway894345 7y ago
    I fully agree with this assessment, but I don’t see how this puts Python’s story on par with Go’s. While GOPATH was certainly idiosyncratic, it generally just worked for me. While go modules aren’t perfect and the history was frustrating, they generally work fine for me. Python feels like an uphill battle by comparison.

sandGorgon 7y ago

Go has had an equally bad packaging experience. Kubernetes - which is one of the biggest projects built in go - has been struggling with dependency and package management. Here's the CTO of Rancher commenting on his struggles https://twitter.com/ibuildthecloud/status/1187529098886664193?s=19 https://twitter.com/ibuildthecloud/status/118752909888666419... https://twitter.com/ibuildthecloud/status/1187538210152308736?s=19 https://twitter.com/ibuildthecloud/status/118753821015230873... This is not trivial stuff..and it shouldn't be trivialised into a go vs python flamewar. Because it can't be.

throwaway894345 7y ago
I've used Python and Go extensively. Go's packaging story has a few rough edges, but Python's is an impenetrable maze of competing tools that each purport to address others' major hidden pitfalls. To work with Python packages, you have to pick the right subset of these technologies to work with, and you'll probably have to change course several times because all of them have major hidden pitfalls: * wheels * eggs * pex * shiv * setuptools * sdist * bdist * virtualenv * pipenv * pyenv * sys.path * pyproject.toml * pip * pipfile * poetry * twine * anaconda To work with Go: * Publish package (including documentation): git tag $VERSION && git push $VERSION * Add a dependency: add the import declaration in your file and `go build` * Distribution: Build a static binary for every target platform and send it to whomever. No need to have a special runtime (or version thereof) installed nor any kind of virtual environment nor any particular set of dependencies.
- ForHackernews 7y ago
  Yeah, until github is unreachable and the entire Go universe grinds to an immediate halt because nothing will build. Python packaging is a mess, but Go doesn't even bother. "Just download from some VCS we'll pretend is 100% reliable and compile from source" is not a packaging solution.
  - kelnos 7y ago
    How is that any different than the entire Python universe grinding to an immediate halt if there's an issue with pypi.python.org? (Hint: it's not.) You can certainly debate the difference in uptime between specific services; I don't know either way, but if you told my that PyPi had higher uptime than GitHub, I'd believe you... but that's kinda missing the point. If you depend on an online service to host your release artifacts, if and when that service goes down, it's gonna hurt. Meanwhile, Python's packaging wars continue to rage on. Go's is simple: a release is a tag in a VCS repository. I'm sure there are issues with that as well, but that should come as no surprise, considering there are issues with literally every packaging solution. At any rate, there's little moral difference between downloading a tarball (or a wheel, or... whatever), vs. pulling a tag from a git repo. It requires equal levels of trust to believe that no one has tampered with prior releases in both cases. I'd like to also point out that I don't have a dog in this race. I've done a little Go here and there, but frankly I don't like the ergonomics of the language too much, so I stay away from it. I've done (and continue to do) a decent amount of Python. I like the language, but tend to prefer strongly-typed, functional languages, and languages with performant runtimes, so I tend to only use it for smaller projects.