3 ms·

Have you tried writing "a quick little server" in Python and deploying it? Packaging and deployment aren't problems in Go OR Python if you're only solving triv

Have you tried writing "a quick little server" in Python and deploying it? Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems. With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go. You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option. I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries. If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.

ashearer 11y ago
Go and Python deployment aren't quite that equivalent. I've seen build and deployment problems over multiple years with widely-used Python libraries including Python-MySQLdb and Python Imaging Library (PIL). The Go equivalents for such essential libraries are typically in pure Go, so it's much easier to avoid C build and link errors when choosing project dependencies. The prevalence of pure-Go libraries is likely to remain high in the long term even as Go's base of libraries expands.
- devishard 11y ago
  C build and link errors are only one of a myriad of issues that one can have with packaging. I've had far more problems with badly-managed packages in pure Python than with stuff like PIL. And one only has to look as far as JavaScript to see that pure native language dependencies won't save you. I stand by what I said: give it a decade and Go packaging will be just as miserable as packaging in any other language.

ashearer 11y ago

Go and Python deployment aren't quite that equivalent. I've seen build and deployment problems over multiple years with widely-used Python libraries including Python-MySQLdb and Python Imaging Library (PIL). The Go equivalents for such essential libraries are typically in pure Go, so it's much easier to avoid C build and link errors when choosing project dependencies. The prevalence of pure-Go libraries is likely to remain high in the long term even as Go's base of libraries expands.

devishard 11y ago
C build and link errors are only one of a myriad of issues that one can have with packaging. I've had far more problems with badly-managed packages in pure Python than with stuff like PIL. And one only has to look as far as JavaScript to see that pure native language dependencies won't save you. I stand by what I said: give it a decade and Go packaging will be just as miserable as packaging in any other language.